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Abstract 


In numerous user-centric, cyber-physical systems, point collection and redemption mechanisms 
are a core component. Loosely speaking, this component or building block may be viewed 
as personal “piggy bank” that allows users to deposit and disburse points. Depending on the 
context, points might be interpreted in numerous ways: monetary units (e.g. Euro cents), 
loyalty rating points, reliability credits, etc. This thesis deals with the problem of anonymous 
point collection. 

Applications which are currently deployed in practice typically bind the stored value to some 
ID (e.g. the serial number of a card) or even worse to a user account. In other words, existing 
systems do not provide anonymity for the participating users, are at best only pseudonymous 
and allow to link transactions that belong to the same user. This enables tracing a user’s 
movements. In the literature, several privacy-preserving solutions have been proposed which 
target specific scenarios: inter alia (anonymous) e-cash, anonymous reputation systems, loyalty 
systems as well as incentive systems. None of these consider anonymous point collection as a 
generic, multi-purpose building block. While the latter does not need to be a disadvantage per 
se, the proposed solutions are typically very restricted (e.g. only look at the specific aspect of 
point deposition), or completely ignore important features (e.g. blacklisting) which might be 
required for practical deployment. Moreover, a majority of them lack formal security models, 
not to mention security proofs and rely on the hope that some vague notion of security and/or 
privacy is satisfied. 

This thesis aims at two goals. 

First and foremost, this thesis is a comprehensive, formal treatment of anonymous point 
collection as a generic building block together with a rigorous security model and proof. To 
this end, a definition of anonymous point collection is carved out which does not only provide 
a strong notion of security and privacy, but also covers features which are essential for practical 
use. Thereby, the proposed definition broadens the applicability of such a building block in 
real-world scenarios. As a pure definition is hollow, if it cannot be fulfilled, this thesis includes 
a practically efficient realization which also has been implemented on real-world hardware. 
This realization is rigorously proven to be secure with respect to the proposed definition. 

Despite the formal methodology, the prospect of a practical efficient realization is already 


reflected by the definition of the envisioned building block. Cryptography has shown that—in 
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principle—any computable function whose inputs might be distributed across mutual distrustful 
parties can be securely evaluated using so-called secure multi-party computation (MPC). 
However, generic MPC techniques are too inefficient for real-world applications and also come 
with a number of other drawbacks. Hence, research on the intersection between IT security 
and cryptography considers tailor-made building blocks which allow both a practically efficient 
realization but are also provably secure with respect to a precise definition. Therefore, the 
main challenge is to find a definition of security that is not overly idealized and thus cannot be 
realized on the one hand, but still captures a meaningful concept of security and is not too 
weak on the other hand, while allowing for a practically efficient realization at the same time. 

The most important contribution of this thesis is to find that definition. Even in disregard of 


the extended features, the resulting building block is the first one that 
(1) allows for anonymous two-way transactions, 
(2) has (periodic) offline capabilities, 
(3) requires only constant storage size (with respect to the stored value), and 
(4) is provably secure. 


The second and much more subtle goal of this thesis is to contribute to the question how 
security for complex systems should be defined. Besides game-based security definitions, 
simulation-based security definitions have turned out to be particularly prolific. In modern 
cryptography, new schemes or improved realization for existing schemes nearly always come 
together with a precise definition of their security and a corresponding proof. However, the 
building blocks which are considered in cryptography are traditionally rather simple objects 
(e.g. encryption schemes, signature schemes, commitment schemes, etc.). At least, they are 
much simpler than a building block for anonymous point collection which we deem a complex 
system. Conversely, in the field of IT security, which considers larger systems, strict security 
proofs in the cryptographic sense are frequently missing. This thesis aims at having a share in 
closing this gap. To this end, the traditional way to define a list of certain desired properties of 
the envisioned system is combined with the simulation-based Universal Composability (UC) 
framework. Evidence is given throughout the thesis that using this combined approach leads to 
improved security guarantees compared to a plain game-based approach. On the one hand side, 
this combined approach thus seems to be the right choice and might serve as a blueprint for 
comparably complex systems. On the other hand side, it also becomes obvious that a UC-based 
definition happens to be viable but yields cumbersome and bulky proofs. The thesis broaches 
the question, if this effect has a more fundamental cause which might be the starting point of 


further research. 


Zusammenfassung 


Das Sammeln und Einlósen von Punkten stellt in unzáhligen nutzerzentrierten, cyber-physika- 
lischen Systemen eine zentrale Komponente dar. Salopp ausgedrückt kann diese Komponente 
oder dieser Baustein als ein persönliches „Sparschwein“ betrachtet werden, welches dem Nutzer 
ein Ein- und Auszahlen von Punkten ermóglicht. Je nach Anwendungsfall ergeben sich verschie- 
dene Interpretationen der Punkte: als Geldeinheiten (z.B. Eurocent), Loyalitatsbonuspunkte, 
Zuverlássigkeitsbewertung, etc. Die vorliegende Arbeit bescháftigt sich mit dem Problem des 
anonymen Punktesammelns. 

Derzeit in der Praxis eingesetzte Anwendungen verknüpfen den gespeicherten Punktestand 
typischerweise mit einer ID (z.B. der Seriennummer einer Karte) oder sogar direkt mit einem 
Nutzerkonto. Damit bieten existierende Systeme dem teilnehmenden Nutzer keinerlei Anony- 
mitát, sondern im besten Fall lediglich Pseudonymitat und erlauben, einzelne Transaktionen, 
die zum selben Nutzer gehóren, miteinander zu verketten. Dies ermóglicht, ein Bewegungsprofil 
des Nutzers zu erstellen. In der kryptographischen Literatur sind verschiedene, privatsphä- 
reschützende Lósungen für spezifische Szenarien vorgeschlagen worden: unter anderem (an- 
onymes) E-Cash, anonyme Reputationssysteme, Loyalitátssysteme und Anreizsysteme. Keine 
der vorgeschlagenen Lósungen betrachtet anonymes Punktesammeln als einen generischen 
Mehrzweckbaustein. Auch wenn Letzteres nicht per se nachteilig ist, sind die Lösungen häufig 
sehr beschränkt (bspw. wird nur der spezifische Aspekt der Punkteinzahlung betrachtet) und 
wichtige Zusatzfunktionen (bspw. das gezielte Ausschließen von Nutzern), die jedoch für die 
praktische Verwendbarkeit notwendig sind, bleiben unberücksichtigt. Darüber hinaus lässt 
eine Mehrheit der Vorschläge formale Sicherheitsmodelle, geschweige denn Sicherheitsbeweise, 
vermissen. Sie basieren vielmehr auf der Hoffnung, dass ein nur vage spezifizierter Sicherheits-/ 
Privatsphärebegriff irgendwie erfüllt sei. 

Diese Arbeit verfolgt zwei Ziele. 

In erster Linie ist diese Arbeit eine umfassende, formale Betrachtung des anonymen Punkte- 
sammelns als generischer Baustein inkl. eines präzisen Sicherheitsmodells und -beweises. Zu 
diesem Zweck wird eine Definition für anonymes Punktesammeln herausgearbeitet, die nicht 
nur einen starken Sicherheits- und Privatsphärebegriff bietet, sondern auch praktisch relevante 
Leistungsmerkmale abdeckt. Damit erweitert die vorgeschlagene Definition die Anwendbarkeit 


eines solchen Bausteins in realen Szenarien. Da eine reine Definition, welche nicht erfüllt 
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werden kann, substanzlos ist, beinhaltet diese Arbeit auch eine praktisch effiziente Realisierung, 
die auf realer Hardware implementiert wurde. Diese Realisierung wird als sicher bzgl. der 
vorgeschlagenen Definition bewiesen. 

Trot, der formalen Methodik zeigt sich das Ziel einer praktisch effizienten Realisierung bereits 
in der Definition. Die Kryptographie hat gezeigt, dass es prinzipiell móglich ist, jede beliebige, 
berechenbare Funktion, deren Eingabe über verschiedene, sich paarweise misstrauende Parteien 
verteilt sein kann, mit Hilfe sog. sichererer Mehrparteienberechnung (MPC) auszuwerten. 
Generische MPC-Techniken sind jedoch zu ineffizient für reale Systeme. Die Forschung an der 
Schnittstelle zwischen IT-Sicherheit und Kryptographie betrachtet daher maßgeschneiderte 
Bausteine, die sowohl eine praktisch effiziente Umsetzung erlauben, als auch beweisbar sicher 
bezüglich einer präzisen Definition sind. Die wesentliche Herausforderung ist somit, eine 
Definition zu finden, die auf der einen Seite nicht überidealisiert und somit unerfüllbar ist, aber 
auf der anderen Seite dennoch einen sinnvollen Sicherheitsbegriff bietet, der zudem auch eine 
praktisch effiziente Realisierung ermóglicht. 

Der wichtigste Beitrag dieser Arbeit ist, eine solche Definition zu finden. Auch ohne Berück- 
sichtigung der zusátglichen Leistungsmerkmale ist der resultierende Baustein der erste seiner 


Art, der gleichzeitig 
(3) anonyme Zwei-Wege-Transaktionen ermóglicht, 
(2) konstanten Speicherbedarf besitst (bzgl. des gespeicherten Werts), 
(3) offline einsatzbar 
(4) und beweisbar sicher ist. 


Das zweite und deutlich subtilere Ziel dieser Arbeit leistet einen Beitrag zu der Frage, wie 
Sicherheit für komplexe Systeme definiert werden sollte. Neben spielebasierten Sicherheits- 
definitionen haben sich simulationsbasierte Sicherheitsdefinitionen als besonders fruchtbar 
herausgestellt. In der modernen Kryptographie werden neue Verfahren oder verbesserte Rea- 
lisierungen vorhandener Verfahren nahezu immer zusammen mit einer präzisen Definition 
ihrer Sicherheit und einem zugehórigen Beweis vorgeschlagen. Allerdings sind die von der 
Kryptographie betrachteten Bausteine traditionell eher einfache Objekte (z.B. ein Verschlüsse- 
lungsverfahren, ein Signaturverfahren, ein Commitment-Verfahren, etc.), zumindest deutlich 
einfacher als ein Baustein für anonymes Punktesammeln, welcher im Folgenden als komplexes 
System betrachtet wird. Im Gegenzug fehlen im Bereich der IT-Sicherheit, welche größere 
Systeme betrachtet, háufig strenge Sicherheitsbeweise im Sinne der kryptographischen Me- 
thodik. Diese Arbeit möchte einen Beitrag dazu leisten, diese Lücke zu schließen. Zu diesem 


Zweck wird der traditionelle Ansatz, eine Liste wünschenswerter Eigenschaften des anvisierten 
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Systems zu definieren, mit dem simulationsbasierten UC-Framework kombiniert. Anhand 
verschiedener Aspekte des Systems wird diskutiert, wie dieser kombinierte Ansatz gegenüber 
einer rein-spielebasierten Modellierung zu verbesserten Sicherheitsgarantien führt. Einerseits 
scheint dieser Ansat; somit grundsäßlich der richtige Weg zu sein und könnte als Blaupause 
für vergleichbar-komplexe Systeme dienen. Andererseits wird jedoch auch offensichtlich, dass 
eine UC-basierte Definition zwar grundsátglich ein gangbarer Weg ist, jedoch zu sperrigen, 
schlecht-handhabbaren Beweisen führt. Die Frage, ob diesem Effekt ein grundsátglicheres Pro- 


blem zugrunde liegt, wird andiskutiert und kónnte Ausgangspunkt für weitere Forschung sein. 


1 Introduction 


This thesis proposes a flexible security model and cryptographic protocol framework designed 
for a new cryptographic building block that enables anonymous point collection. To the best 
of the author’s knowledge, this work is the first with a rigorous security definition and proof 
which capture all aspects of such a building block in an integrated model. Furthermore, it is 
unarguably the most comprehensive formal treatment of anonymous point collection overall. 
The framework is very flexible in the sense that auxiliary features (e.g. blacklisting of users, 
selective unveil of individual transactions) which might be required in certain applications are 
included in the definition, but each can just as well be omitted individually, without changing 
any other part of the system or sacrificing security. 

The need for such a building block is obvious from the multitude possible applications. The 
abstract notion of points can be interpreted as monetary units (e.g. Euro cents), loyalty rating 
points, reliability credits, etc. 

In the scope of loyalty programs prominent examples are the German Payback system 
[PAY16] or the UK-based Nectar program [Aim16]. 

Complementary currencies are commonly used by providers of physical services to restrict 
access on a pre-payment basis. Typical examples are trading cards for regional public trans- 
portation systems, like the Oyster Card for the London underground railway [Tra19], access 
cards for natatoriums, or campus payment systems for canteens and alike [ven19; Cou19]. Here, 
customers first top-up their wallet (typically in form of an ID-1 card) which is then charged per 
usage. But also, post-payment variants exist, in which the users collect debt first and clear it 
later. In the scope of cashless payment systems, electronic toll collection (ETC) is of particular 
interest. ETC is already deployed in many countries all over the world with an estimated 
annual turnover of 10.6 billion US dollars by 2022 [Marı7]. The EU plans to introduce the first 
implementation of a fully interoperable tolling system (EETS) by 2027 [ECı7]. 

Reliability (or reputation) assessment is used in various interactive systems to curtail riot 
behavior. When entering the system, new users only have a limited choice of options how 
to interact with the system, but long-term users can gain access to more advanced options 
(and more harmful options if misused) depending on their reputation level. Basic examples are 
Internet forums where new users can post new messages and edit their own ones, but must not 


edit or even delete other posts until they have demonstrated responsible behavior. In Vehicle- 
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to-Grid scenarios [KTos], owners of e-vehicles are not only paid for the buffer capacity which 
the batteries of their e-vehicle provide to the grid when cars are parked at the mall, office, etc., 
but the grid operator also needs to rate the soundness of users’ declarations how long their 
cars will be connected to the grid in order to predict their availability and to create precise 
forecasts for the grid management. This requires means to rate the reliability of (anonymous) 
individuals in order to spot owners of e-vehicles which frequently leave before the stated time. 

Lastly, the same mechanism is used to incentify particular behavior. For instance, in envi- 
sioned mobile sensing scenarios [Chr+11], users should be encouraged to collect environmental 
or health data measured with their smart devices and provide this data (enhanced by location 
and time information) to some operator. In exchange, users receive micropayments they can 
use to pay for services based on the collected data. 

Unfortunately, the systems in use today do not protect the privacy of their users and are 
identifying or only pseudonymous at best. The latter still allows transactions to be traced and 
linked to the same user. Surely, in some scenarios (e.g. loyalty programs), identification and 
traceability of users is part of the business interest in order to enable other business relevant 
purposes like, e.g., personalized advertising. But in many scenarios personal information 
is only a by-product which is (falsely) deemed unavoidable to manage individual wallets or 
accounts. For example, in the cases of campus cashless payment systems, the ETC scenarios 
or access cards, the operator of such a system, e.g. the caterer of the canteen or the operator 
of the natatorium, is interested into what has been purchased how often, but is usually not 
interested (or should not be interested) who has done the purchase. Having the personal 
information nonetheless encourages abuse or accidental theft of data. Thus, an efficient and 
cost-effective privacy-preserving mechanism which avoids data collection in the first place, 
but still enables the billing functionality, should be of interest to the providers as well. In this 
way, there is no need to deploy costly technical and organizational measures to protect a large 
amount of sensitive data and there is no risk of a data breach resulting in costly law suits, fines, 
and loss of customer trust. This is especially interesting in view of the new EU General Data 
Protection Regulation (GDPR) [EC18] which is in effect since May 2018. The GDPR stipulates 


comprehensive protection measures and heavy fines in case of non-compliance. 


11 Related Work 


When considering the related work of our anonymous point collection scheme, the collection of 
work to be looked at heavily depends on what perspective on the anonymous point collection 
scheme is chosen. The more application-oriented way is to directly look at the anonymous 
point collection system as some kind of anonymous e-cash system or at a concrete scenario 


which involves a specific kind of points, e.g. in the scope of a customer loyalty program or 
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an anonymous reputation program. However, we would like to focus more on the aspects of 
anonymous point collection as a generic, multi-purpose building block. From this point of 
view our anonymous point collection scheme can be used to build the aforementioned systems 


but is not exclusively limited to these applications. 


1.1.1 Application-specific Proposals 


Except for [JR16; Mil+15] which are discussed in Section 1.1.3 the cryptographic literature 
has not considered anonymous point collection as a generic building block before. In the 
following, a brief overview of rather application-centric work is given. Among the proposed 
solutions for scenarios comparable to our goal the literature on (anonymous) e-cash and 
payment systems [CHLo5; Bal+15; Rup+15; AIRo1; Bel+08; ILV11; Gar+08; KHGo8; Gar+09], 
anonymous reputation systems [AK12; AKS12], anonymous loyalty systems [EFSo4; BD15] 
and anonymous incentive systems [Mil+15; Gon+15] is most notable. For the specific task of 
privacy-preserving, electronic toll collection (ETC) many ideas have been proposed as well 
[JCV35; Jar+14; Jar+16; Day+11; Bar+16; PBBog; Bal+10; Mei+11]. 

At first sight, the problem of anonymous point collection might appear easily solvable using 
(offline) e-cash, if each point is assumed to correspond to a single e-coin. In order to collect 
points, the users and the operator may execute the protocol to withdraw one e-coin repeatedly 
for each point. All collected coins may later be redeemed using the protocol for spending 
coins (multiple times). However, besides being inefficient, because coins typically cannot be 
aggregated, this also violates user privacy as in traditional offline e-cash, e.g. [CHLos], the 
withdrawal of e-coins is identifying. This is an unavoidable necessity, because a user's identity 
needs to be encoded into an e-coin during withdrawal to enable double-spending detection. 
Even transferable e-cash, e.g. [Bal+15], does not achieve the anonymity goal of this work. In 
such a scheme, the ownership of an e-coin can be transferred anonymously and unlinkably 
between users multiple times without the help of the bank. However, an impossibility result 
by Canard and Gouget [CGo8] implies that an adversary impersonating the operator and the 
point-of-sale would be able to link a user’s transactions. Moreover, transferable e-cash allows 
users to transfer e-coins arbitrarily among each other, a property which is undesirable in some 
of our envisioned scenarios as users would be able to pool their points. 

A loyalty system is meant to reward users (most often a customer) for being steady partners 
of some other party (usually a merchant). In the easiest case users collect points for their 
participation in some action and later redeem those points. Enzmann, Fischlin, and Schneider 
II [EFSo4] introduce two privacy-friendly loyalty systems for electronic market places. Their 
counter-based solution builds on RSA blind signatures. Blanco-Justicia and Domingo-Ferrer 


[BD15] propose a loyalty system which uses partially-blind signatures in pairing-based groups 
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to ensure anonymity. Milutinovic et al. [Mil+15] present an unlinkable multi-purpose incentive 
scheme. The scheme draws from zero-knowledge proofs, commitment schemes, and partially 
blind signatures. Recently, Gong et al. [Gon+15] propose a privacy-preserving incentive-based 
demand and response scheme building on identity-based signatures, partially blind signatures 
as well as proofs of knowledge. 

A reputation system provides the means to rate the behavior of parties in a system in order 
to support other parties in deciding whom to trust. In the simplest case, reputation equals 
the sum of (positive and negative) individual rating values. Systems providing rater and ratee 
privacy in peer-to-peer systems can be built from e-cash and anonymous credentials as, e.g., 
shown by [And+08]. Building on blacklistable anonymous credentials [Tsa+o7], several papers 
(e.g., [AKiz; AKS12]) have been published, dealing with TTP-free reputation-based blacklisting, 
where a central authority (like Wikipedia) may score the actions of its anonymous users. 

Unfortunately, a lot of the aforementioned work frequently lacks a formal security model, a 
precise statement of what security goal is archived and/or rigorous proofs of security. Moreover, 
some of the papers were written with a particular use case in mind and implicitly assume that 
parties exhibit a particular behavior, i.e. they do not consider maliciously acting adversaries 
in the cryptographic sense but “rational” adversaries. Yet another set of applications which 
benefit from stronger security, offline capabilities, and negative points, are pre- or post-payment 
systems. In practice, such payment systems are typically implemented using simple RFID- 
transponder or smartcard-based solutions like the MiFARE Classic [NXP14], which essentially 
offers no security and privacy at all [Gar+08; KHGo8; Gar+og, and more], or the MiFARE 
DESFire [NXP16; OP11] also allowing to link all transactions. Therefore, we prefer to look 
at anonymous point collection as an application-independent building block with a proper 
formalization of its functionality, its security and its privacy properties. For details how to use 
anonymous point collection to build some of the applications see Section 2.3. For a discussion 
of the long list of proposals for the electronic toll collection (ETC) scenario [JCV15; Jar+14; 
Jar+16; Day+11; Bar+16; PBBog; Bal+10; Mei+11; DDS12; Che+13] the reader is referred to Nagel 
et al. [Nag+20], which has been co-authored by the author of this thesis. There, the authors 
demonstrate how the proposed anonymous point collection scheme can be used to construct 
an ETC system. In summary, it seems fair to say that previous solutions for that domain have 
mostly been proposed by practitioners and also lack—apart from a few exceptions [DDS12; 


Che+13; Bal+10]—any formal security analysis. 


1.1.2 Proposals with Similar Constructions 


Our proposed anonymous point collection scheme shares some resemblance with the notion of 
a priced oblivious transfer (POT). POT was introduced by Aiello, Ishai, and Reingold [AIRoı] as 
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a tool to allow a customer to purchase digital goods from a merchant without leaking the “what, 
when and how much”. However, privacy of the customer (or user in our scenario) is not granted 
and the original POT scheme is inherently limited to a single point-of-sale. A POT is a two-party 
protocol between the customer and the merchant. The merchant owns a set of messages and 
tags each of the messages with a price. The customer is allowed to receive a subset of the 
messages such that their total price does not exceed a specific limit. A POT scheme guarantees 
that the customer does not learn anything about the messages which have not been picked and 
that the merchant does not learn anything at all. The envisioned scenario is the purchase of a 
set of cryptographic keys which in a later step allow the customer to access a DRM-protected 
digital good (i.e. software licenses, video-on-demand, etc.). Camenisch, Dubovitskaya, and 
Neven [CDNio] extend POTs by anonymity of the customer and unlinkability of individual 
transactions which brings it closer to our scheme. The protocol is based on two different 
signature schemes [ASMo6; BBo4], the set membership protocol from [CCso8] and zero- 
knowledge proofs. Nonetheless, the scheme is still limited to a single merchant (but with 
multiple users). Moreover, [CDNio] lacks a full rigorous formal treatment. Rial and Preneel 
[RP10] extend POTs by optimistic fairness such that both parties can appeal to a third party in 
case of a dispute. 

In some other aspects our anonymous point collection scheme exhibits similarities to P- 
signatures [Bel+08; ILV11] which have been introduced by Belenkiy et al. [Bel+08] as a tool 
to construct anonymous credentials. The scheme involves a set of users and an issuer. The 
scheme combines the algorithms of a commitment scheme and a signature scheme and extends 
them by two algorithms that allow the user to prove that (1) two commitments contain the 
same message, and (2) the user knows a valid signature under the issuer's private key on a 
message inside the commitment, resp. The scheme in [Bel+08] builds on weak Boneh-Boyen 
signatures [BBo4], Groth-Sahai commitments and Groth-Sahai NIZK proofs [GS08]. Although 
their construction shares many ideas with ours, there are at least two major differences: 
(1) Our building block allows to homomorphically modify the commitments and obtain new 
signatures which is essential for “depositing points" while [Bel+08] only allows to re-randomize 
commitments. (2) P-signatures do not include a mechanism to prevent users from showing 
different commitments to the same message twice. Skipping ahead, such a mechanism is 
required for double-spending detection (see later) but is not required for standard anonymous 


credentials. 


1.1.3 Generic Proposals—uCentive and BBA 


Besides [JR16], only [Mil+15] appears to consider a point collection mechanism as a multi- 


purpose building block on its own. However, the proposed protocol—called uCentive—targets 
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a simpler scenario than we do: incentives are not accumulatable on the user’s side but stored 
and redeemed individually, negative points are not supported, and double-spending detection 
is done online rather than offline. uCentive also differ regarding the use of cryptographic 
building blocks: uCentive makes use of anonymous credentials and partially blind signatures. 
Unfortunately, the security and privacy properties of their protocol are again only informally 


stated and no proofs are given. 


Jager and Rupp [JR16] have recently introduced BBA (Black-Box Accumulator) as a generic 
building-block for a curtailed variant of anonymous point collection. They formalized the core 
functional, security, and privacy requirements for a variety of user-centric protocols such as 
loyalty, refund, and incentive systems. As their work is the starting point for [Nag+17; Nag+20], 
which in turn are the base of this thesis, [JR16] is discussed in more detail. Differences between 


[JR16] and this work are also detailed out in Section 1.2. 


BBA consists of a set of non-interactive algorithms to generate, manipulate, and show 
statements about BBA tokens (aka piggy banks or wallets). The scheme stipulates four types of 
parties: a set of users, an issuer, a set of accumulators and a verifier. However, as the issuer, 
all accumulators and the verifier share the same public-private key pair and must completely 
trust each other, they are better regarded as a single party. BBA allows a user to collect positive 
points (representing incentives) in an anonymous and unlinkable fashion. In the beginning, a 
user receives a BBA token generated by the issuer which is bound to a unique serial number 
known to both parties. This serial number remains constant during the lifetime of a token.’ 
All points are collected using this single, constant-size accumulation token. To this end, a 
user blinds and unblinds the token before and after every transaction with an accumulator. 
When redeeming the token, the sum of all collected points as well as the initial serial number 
is revealed to the verifier. Obviously, obtaining and redeeming a BBA token is a linkable 
operation as the serial number of the token is revealed in both operations. After a token has 
been redeemed, it must not be used again. A permanent connection to a database containing 
serial numbers of tokens already redeemed is required in order to prevent double-redemption 
(aka double-spending) of tokens. Hence, BBA schemes are online systems. Also, users can 
re-use an old state of their token when points are accumulated without being detected. For 
this reason, “negative” points are not supported as users could easily get rid of them. Jager 
and Rupp [JR16] assume that positive points (i.e. incentives) are beneficial for users and thus a 


“rational” adversary has no interest in re-using an old state of a token. 


1 We stress that a serial number in [JR16] must not be confused with a serial number in this thesis. The serial 


numbers of [JR16] are better compared to wallet ID in this work. Both remain constant during the lifetime of a 
token or wallet, resp., and thus are identifying for the token/wallet. Serial numbers in the sense of this work 
denote single transactions, i.e. the deposition or disbursement of points, and do not exist in [JR16]. 
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Moreover, the authors formalize a rather weak form of security, by only demanding that 
a collusion of malicious users may not be able to redeem more points than the total amount 
of points issued to them. In particular, this does not rule out that users may transfer points 
arbitrarily between their BBA tokens (without help). Normally, non-interactive schemes are a 
highly desired goal in cryptography, because non-interactive schemes have little communication 
complexity and are therefore typically very efficient. But the (non-interactive) algorithms of 
[JR16] are rather artificial. For example, the activity of adding points to a BBA token is not a 
single protocol, but willfully split into three algorithms which are (forcibly) non-interactive. 
First, users locally mask their tokens (to enable anonymity) using the first algorithm, then 
the blinded token is handed over to the accumulator outside the scope of the model, the 
accumulator locally manipulates the token using the second algorithm, the new token is given 
back to the users outside the scope of the model, and finally users locally unmask their tokens 
again using the third algorithm. This approach yields non-interactive algorithms at the cost of 
a direct semantic interpretation of these algorithms and it is not immediately clear what kind 
of security is achieved. 

To summarize, the original BBA framework suffers from a number of serious restrictions 


including: 
(1) fairly weak security guarantees, 
(2) the need of a permanent database connection, 
(3) the lack of mechanisms to enforce the collection of negative points, and 
(4) the linkability of token creation and redemption. 


These shortcomings limit the applicability of BBA as a building block. For instance, operators 
of loyalty or reputation systems do not want their users to pool or trade their points. Also, in 
certain scenarios negative points might be required. To realize this feature with a BBA scheme, 
one would need to redeem all points on a token, create a new one, and charge it with the 
remaining (unspent) points. However, in this way all partial redemptions of a user are linkable. 
Finally, BBA does not provide any of the auxiliary features (like blacklisting, etc.) which are 
required for practical use. 

In [Nag+17], Nagel et al. propose BBA+ (Black-Box Accumulator Plus) which rectifies many 
of the drawbacks of the original BBA scheme [JRı6]. But [Nag+17] still misses an integrated 
security model which captures both security for the operator and privacy for the users in 
a unified model. This and other issues are addressed by Nagel et al. in [Nag+20]. Both are 


discussed in the following section. 
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12 Contribution 


This thesis is mostly based on [Nag+17; Nag+20], but also goes beyond those. Before the 
combined contribution of [Nag+17; Nag+20] and this work over previous proposals will be 
described, we shortly sketch their evolution. 

BBA+ [Nag+17] improved over BBA [JRı6] by offline capabilities, the support for negative 
points, the prevention against the pooling of points between users and a double-spending 
mechanism. Also, the definitional part has mostly been rewritten. BBA+ considers interac- 
tive protocols which leads to more intuitive definitions and broadens the class of possible 
instantiations. For example, the definition of a BBA* scheme imposes less restrictions on an 
instantiation, as the definition only stipulates a single protocol for the deposition of points 
instead of three non-interactive algorithms. This also allows to formalize the security proper- 
ties of BBA+ in a more natural as well as stronger way. However, in [Nag+17] security (incl. 
correctness) for the operator on the one hand and privacy for the users are still considered to be 
distinct aspects. Security is still defined by a list of properties that are individually proven in a 
game-based approach which has been inspired by the definition for a pre-payment with refunds 
scheme proposed in [Rup+15]. Privacy for users is defined by a simulation-based approach in 
[Nag+17]. 

In [Nag+20], Nagel et al. use BBA+ to construct a privacy-preserving ETC system. This 
enhances BBA+ by additional features that are essential for such a scenario. With respect to 
practical deployments the lack of these properties is a significant shortcoming of BBA+ and the 
enhancements are also beneficial for other applications of anonymous point collection. Also, 
Nagel et al. [Nag+20] uses the UC-framework to define all security aspects incl. privacy as an 
ideal functionality. 

In this thesis, the functional extensions of [Nag+20] are backported and presented as part 
of a generic building block for anonymous point collection. Moreover, many subtle details in 
[Nag+20] are not formally spelled out, but are only sketched. This mostly concerns the channel 
model (i.e. in which cases communication is anonymous or authenticated and—if authenticated— 
at which point during the execution the identities are learned) and the synchronization of the 
distributed state between the different parties. In this thesis these seemingly minor details are 
straightened out as well. This has not only been a pure formality for the sake of completeness, 
but unveiled several oversights in [Nag+20]. Fixing these flaws necessitated modifications on 


the protocol level but also adjustments to the security model. 


1.2.1 System Definition, Security Model and Proof 


This thesis presents a framework for anonymous point collection which addresses the restric- 


tions of BBA discussed in Section 1.1.3, thereby significantly strengthening its security and 
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broadening its applicability. For the scenario which is detailed out in Chapter 2, we propose an 


ideal functionality 9,,. for anonymous point collection based on the UC framework [Cano]. 


Typically, the standard approach is to cast a complex system like 9,,. as an MPC problem and 


then resort to generic but inefficient UC-secure MPC [IPSo8; Can+o2]. Our work is one of very 


few combining a complex, yet practical crypto system with a thorough UC security analysis. 


Our framework improves over previous work in the following aspects: 


(1) 


(2) 


(3) 


(4) 


(5) 


The definition of anonymous point collection is captured as a single ideal functionality 
Tape in the UC-framework with (polynomially) many parties that reactively participate 
in (polynomially) many transactions. This leads to a very precise demarcation of the 


system with a clean interface and thus yields numerous advantages: 


(a) The security of BBA [JR16] (and even BBA+ [Nag+17]) has been modeled by for- 
malizing each security property individually as it is usually done in a game-based 
setting. This approach bears the intrinsic risk that important and expedient security 
aspects are overlooked, e.g., the list is incomplete. This danger is eliminated by the 
UC-approach where we do not aim to formalize a list of individual properties but 


rather how an ideal system should look like. 


(b) The definition fpc allows interactive protocols, and thus poses less restrictions on 


possible realizations. 


c) A single ideal functionality #,. which encompasses a complete sequence of trans- 
8 Y Jape P p q 
actions allows for a very "strong" variant of security and privacy with an intuitive, 


semantic interpretation. 


The definition formalizes a stronger and more natural security property which demands 
that the balance of a wallet must be exactly the amount legitimately collected with this 


wallet. In other words, the pooling of points between wallets is ruled out. 


The definition supports the deposition of negative points and stipulates a mechanism to 


identify users who do not use the most recent state of their wallet. 


The definition covers offline realizations in the sense that there does not need to be a 
permanent connection to a database to check whether a presented wallet has already 


been robbed. 


We define a strong form of privacy, namely forward and backward unlinkability of 
transactions: A malicious adversary, including a collusion with the system operator, 
must neither be able to associate transactions to a particular wallet of an honest user nor 


be able to link preceding and succeeding transactions with each other. This even holds in 
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(6) 


(7) 


case a user commits double-spending (for those realization that allow double-spending 
with subsequent identification). The set of unlinkable transactions not only includes the 


deposition but also disbursement of points. 


The definition stipulates different parties with whom users can interact. Inter alia, an 
operator who runs the network and issues wallets to users and PoSes which deposit/dis- 
burse points to/from the wallets of users. Opposed to [JR16], the definition indeed 
enforces these parties to be actually distinct through the corruption model, i.e. by limit- 
ing what an adversary learns if, for example, a single PoS is corrupted. In other words, 
the definition of Apc rules out realizations which use a shared secret key for all non-user 
parties and which assume complete trust among these parties. To this end fpc envisions 


the certification of individual PoSes. 


To broaden the practical applicability fpc functionally extends [JR16] in several ways. 


(a) The definition demands the existence of several auxiliary features which deal with 
potential “real-world” issues like broken hardware, legal disputes and so on: (i) A 
blacklisting mechanism that allows to exclude individual wallets or all wallets of a 
user from the network. (ii) A recalculation mechanism that allows to recalculate or 
restore the “true” balance of a wallet in case of a dissent, in case of double-spending 
or broken hardware. (iii) A prove-participation mechanism that allows users to 
selectively unveil a single transaction and thereby prove their participation without 
compromising the unlinkability of other transactions (including their own). Note 
that some of these features either premise the consent of the user (otherwise the 
operator could break unlinkability on its own) or a third party which serves as a 


dispute resolver and enables a key-escrow mechanism. 


(b) To enforce the collection of negative points which users may not voluntarily collect, 
the system optionally includes a party called violation enforcer to re-establish 


fairness. 


(c) Lastly, as a minor detail, fpc allows user and PoS attributes on which the price of a 
transaction may depend. Also, the attribute can be used to bind wallets to a billing 
period which is encoded in the attribute. Although this extension seems trivial it 
has a great impact in practice. It does not only allow more complex pricing models 
but additionally increases real-world performance. By making PoSes only accept 
wallets from the current period, the size of the blacklist checked by the PoS can be 
limited to enable fast transactions. Similarly, the database needed to recalculate 


balances can be kept small. 


1.2 Contribution 


A major challenge in designing ape was to combine provable security and practicality, where 
the latter includes practical performance figures. Hence, the difficulty was to find a definition 
that yields a reasonable trade-off between various aspects: On the one hand, it needs to be 
sufficiently abstract to represent the semantics of anonymous point collection which allows the 
formalization strong security features. If 7). was aligned more closely to a concrete realization, 
this would artificially restrict the set of admissible realization, introduce unnatural artifacts 
and thereby weaken the provided security guarantees. On the other hand, while in principle 
every computationally solvable problem can be cast as an MPC problem, a definition that is 
completely agnostic of a potential realization would certainly lead to very inefficient solutions. 

As stated above, the proposed definition captures the problem of anonymous point collection 
within a single ideal functionality pc with polynomial many parties. This makes the security 
analysis and proof highly non-trivial and cumbersome, because a high number of combinations 
which parties are corrupted needs to be considered in the proof. At first sight, it seems tempting 
to follow a different approach: In many tasks? of the system only specific parties interact with 
each other while the majority of parties is not involved. For example, a single user and a single 
PoS interact with each other in order to deposit points to the user's wallet. In a similar spirit, 
most tasks only involve two parties. This observation makes it temping to de-compose the 
system into a set of two-party tasks, define an ideal functionality for each of these tasks, realize 
each of them by a protocol, analyze their security separately and deduce the security of the 
system using the UC composition theorem. However, this entails a slew of technical subtleties 
due to the shared state between the individual two-party protocols which cannot easily be 
solved. 

Moreover, although our system uses cryptographic building blocks for which UC formaliza- 
tions exist (commitments, signatures, NIZK), these abstractions cannot be used. For example, 
UC-commitments are non-transferable, i.e., the commitment message cannot be passed to a 
different party, but we exploit this property heavily. Abstract UC-signatures are just random 
strings that are information-theoretic independent of the message they sign. Thus, it is impos- 
sible to prove in zero-knowledge any statement about message-signature-pairs. Hence, our 
security proof has to start almost from scratch. Although parts of it are inspired by proofs 


from the literature, it is very complex and technically demanding. 


12.2 Protocols and Implementation 


Besides the definitional framework, this thesis includes a realization zpsc (Provably-Secure yet 


Practical Privacy-Preserving Point Collection) of fpc using advanced cryptographic building 


2 The term “task” has no formal definition. However, we assume that the reader has some intuitive understanding 


of it. For an informal definition see Definition 2.1. 
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blocks and presents promising results of a prototypical implementation on real-world hardware. 
They show that the proposed realization may already be useable in practice, allowing to run 
transactions within a second. 

At a high level, the construction is fairly intuitive and draws from techniques also commonly 
used in any privacy-preserving protocols including e-cash, P-signatures, and anonymous 
credentials. However, there are technical differences to these concepts as explained in Sec- 
tion 1.1.1. Moreover, a major challenge was to twist and combine all these techniques to achieve 
simulation-based security, practicality and efficiency at the same time. 'The concrete selection 
of the right instantiation of building blocks and the fine-tuning how they interplay has to be 
credited to the co-authors of [Nag+17; Nag+20] and not the author of this thesis. 

This proposed realization is a semi-generic construction using public-key encryption, ho- 
momorphic trapdoor commitments, digital signatures, and Groth-Sahai non-interactive zero- 
knowledge proofs over bilinear groups for which the SXDH assumption holds. To achieve 
freshness of tokens, we draw from techniques typically used in offline e-cash systems, namely 
double-spending tags. 

To realize the blacklisting mechanism of users we adopt and adjust an idea from the e-cash 
literature [CHLos]. On a high level this technique is a key escrow mechanism on a per wallet 
basis which allows to link all transactions of the affected wallet with the help of a trusted 
dispute resolver. Skipping ahead, this requires on a technical level to encrypt the seed of a 
PRF under the key of the dispute resolver. This part is tricky due to the use of Groth-Sahai 
NIZKs for efficiency reasons and the lack of a compatible (i.e., algebraic) encryption scheme 
whose message space is in turn compatible with the space of the seed. The author of this thesis 
contributed to this problem in so far that the author adopted a CCA-secure, structure-preserving 
encryption scheme [Cam+11] to the SXDH hardness assumption. 

Other technical challenges arise from building on the Groth-Sahai (GS) proof system. GS- 
proofs are efficient and secure in the CRS model but require particular care, as they are no 
proper proofs-of-knowledge for witness components over Z, and not always zero-knowledge. 
For example, to prove statements about shrinking multi-commitments over Zy, which we use 
to obtain compact tokens and proofs, the employed commitment scheme needs to satisfy a 
non-standard binding property. 

In order to assess the suitability of the proposed realization for real-world applications, 
several variants have been implemented. The user side of the protocols in [Nag+17] has been 
implemented on a commercial off-the-shelf (COTS) smartphone, while the PoS side has been 
implemented on an embedded PC of a turnstile. The proposed protocol in [Nag+20] for the ETC 
system has specifically been implemented on an embedded processor which is known to be 
used in currently available on-board-units such as the Savari MobiWAVE [Savı7]. The biggest 


advantage for real-world deployment originates in the use of non-interactive zero-knowledge 
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proofs, where major parts of the proofs can be precomputed and verification equations can be 
batched efficiently. This effectively reduces the computations which have to be performed by 
the user and the PoS during an actual protocol run. The implementation results show that the 
most time critical task—the deposition of points at a PoS on a user's wallet—can be executed 


within 510 ms. 


12.3 Concomitant Contributions 


Our proposed definition of security and privacy of our building block follows the simulation- 
based paradigm and especially builds on top of the so-called UC-framework [Canoı]. However, 
common saying occasionally states that the UC framework is incompatible with privacy and 
does not allow to define privacy-preserving building blocks. We do away with this tale. To this 
end we first clarify a typical misconception how privacy should be looked at in UC. Second, 
we introduce a new messaging functionality to get rid of the communication model which 
uses identity-based messaging—as we call it—and which is hard-coded into the original UC 
framework without breaking compatibility with the rest of the model. 

In this thesis, the security and privacy of our building block are not considered distinct 
features but captured by a single, uniform definition. With respect to security, the simulation- 
based paradigm is usually contrasted with the game-based approach. The game-based approach 
is sometimes considered to be more natural as each security game is typically associated to a 
single desired objective of the final building block? With respect to privacy, several notions like 
k-anonymity [Sweo2] or e-differential privacy [Dwoo6; Dwooo; Dwo10] have been proposed. 
This thesis suggests an approach which combines all these paradigms. Instead of defining 
a single game for each desired security objective and then applying the game to a concrete 
(cryptographic) realization, the ideal functionality is shown to meet the list of objectives. 
Likewise, the privacy assessment should not be conducted on a concrete realization, but on 
the ideal functionality. The ideal functionality abstracts away the cryptographic complexity 
and “pulls it out of the equation”. As such, the approach followed in this thesis can serve as a 


blueprint for the analysis of similar systems. 


13 Organization of the Thesis 


In Chapter 2 the envisioned scenario is detailed out. The involved parties and their major 


interactions with each other are introduced. As the features of a building block for anonymous 


* One of the (anonymous) reviewer of [Nag+20] declared to feel more confident about the security of the scheme, 


if there was a list of individual security games instead of a single ideal abstraction, because he/she admitted not 
to be able to tell what security the simulation-based definition provides. 
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point collection are dictated by the applications within which the building block is eventually 
deployed, some of these possible applications are discussed in more detail. The chapter con- 
cludes with a list of desired properties one might expect from a building block for anonymous 
point collection. 

As our security model is UC-based, Chapter 3 is an introduction into Universal Composability 
for those readers who are not familiar with this framework. This chapter does not contain 
any own contribution, but is included for self-completeness of this thesis. Also, some very 
common, so-called setup assumptions are provided from the literature. Only, the messaging 
functionality on which the proposed protocol relies is not a pure reproduction, but a merge of 
existing functionalities. 

Given the scenario from Chapter 2, the definition of the proposed building block for anony- 
mous point collection is presented in Chapter 4. The building block is defined as an ideal 
functionality within the UC framework. The functionality is highly non-trivial and nearly a 
protocol on its own as many “real world artifacts” have to be considered. 

Due to its complexity, the definition is reviewed in Chapter 5. This chapter argues why the 
stipulated definition captures the “right definition” of security and privacy for the involved 
parties. Also, we show that the identified properties from Chapter 2 are indeed met by the 
definition. We stress, that this is not the security proof for the proposed protocol as (1) a 
definition cannot be proven and (2) the protocol has yet to be defined. Rather, Chapter 4 
bridges the more traditional gamed-based approach with the simulation-based paradigm. 

Chapter 6 introduces the hardness assumptions, all building blocks (encryption, digital 
signatures, commitments, and alike) and their usual security definitions (IND-CCA, EUF-CMA, 
and alike) are defined. Similar to Chapter 3 this chapter contains no own contribution. Reader 
who are familiar with these building blocks can safely skip this chapter. 

In Chapter 7 a realization of the ideal functionality defined in Chapter 4 is proposed. This 
realization is given in pseudo-code and uses the building blocks from Chapter 6 as black boxes. 

Chapter 8 gives the security proof which shows that the proposed protocol from Chapter 7 is 
actually a realization of the definition from Chapter 4. The proof follows the typical approach 
to define a sequence of hybrids and is rather bulky due to the complexity of the definition. 

Chapter 9 reports figures for a real implementation of the pseudo-code on real-world hard- 
ware. 

Finally, this thesis concludes with Chapter 10. The thesis is summarized, some of the 
encountered difficulties revisited and discussed how they might stimulate further research. 
Also, we sketch some straightforward improvements of this work which are trivial on their 


own but entail a slew of changes in all parts of this work. 
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In a nutshell, anonymous point collection refers to a variety of scenarios in which a set of 
parties—the users—collect or redeem points inside a personal wallet. The system is managed 
by an operator which typically is some kind of legal entity (e.g. a company) whose business 
interest usually is to have as many users as possible using its system.’ Users interact with the 
system at points-of-sale (PoSes) which are setup and maintained by the operator. 

Our proposed scheme P5C (Provably-Secure yet Practical Privacy-Preserving Point Collec- 
tion) is highly flexible and can easily be adopted to different applications. The main design 
parameter is whether the addition and subtraction of points are treated uniformly by the same 
interactive task or if both interactions are treated separately. Another, but strongly related 
design parameter is whether wrap-arounds (i.e. a change of sign of the balance of a wallet) and/ 
or under-/overflows needs to be specially considered or can be ignored. Both design parameters 
heavily influence which tasks are supported by the system, which parties interact in these tasks 
and which “level” of security—or more precisely anonymity—is provided. More, but decoupled 
design decisions relate to the support of optional features like blacklisting. 

For the ease of presentation, we preliminary concentrate on a specific embodiment that 
keeps the addition of points—called deposition—separated from the subtraction of points—called 
disbursement. Also, deposition is anonymous and is carried out between a user and a PoS 
while disbursement is identifying and takes place between a user the operator. We discuss the 
alternatives in Section 2.3. Also, we shortly sketch what needs to be changed for the protocols 


to realize these alternative embodiments whenever convenient during the thesis. 


2.1 Involved Parties 


Our scheme P5C involves the following parties: 


« The Operator which usually is a legal entity and runs the system. It owns and maintains 


the PoSes. Also, it manages a database of users who have registered for participation in 


* Please note, that the users normally do not pay the operator directly in order to participate in the system, but the 
operator is typically reimbursed by some third party for its service. 
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the system and who own a legitimately issued wallet. We stress, the operator does not 


manage the wallets. 


A User participates in the system by means of a (digital) wallet that is kept on a portable, 
personal device. Typically, this is a smartphone or a smartcard, but other devices are 
possible, too. A suitable device must be able to store a few hundred bytes, have some? 
computational power and be able to communicate with the PoSes over some sort of local 
link (e.g. NFC, DSRC, ...). We stress that a permanent online connection is not required. 
Depending on the application, P5C supports multiple wallets per user. In this case a user 
may own several smartcards (one for each wallet) or the application on the smartphone 


allows to select a wallet. 


A Point-of-Sale (PoS) interacts with a user and is managed by the operator. To enable 
fast and reliable transactions with a user, we do not require PoSes to have a permanent 
connection to the operator. We only assume that it is periodically online for a short 
duration to exchange data with the operator. Optionally, it also needs to trigger the 


violation enforcer. 


The Dispute Resolver is an optional party that is necessary, if blacklisting and/or re- 
calculation of a wallet's balance is a required feature. Please remember, that users 
are anonymous when interacting with PoSes. Hence, after users have enrolled for the 
system and have legitimately received a valid wallet, there is no way to prevent a user 
from interacting with a PoS in a user-targeted manner. Also, individual transactions 
are unlinkable with each other or with a particular wallet. If a user claims that the 
balance of his wallet does not match his past transactions or that a particular PoS has 
applied a wrong value to his wallet, there is no way to trace the transactions. If there 
was, this would contradict anonymity. The dispute resolver is an optional third party 
that implements some kind of key escrow mechanism and supports the operator to de- 
anonymize a specific wallet. The dispute resolver must be trusted by the users not to 


collude with the operator. 


The Violation Enforcer is another optional party that might be instrumental in some 
special applications only in case a transaction fails. Please keep in mind, that users are 
anonymous when interacting with PoSes. The question whether a violation enforcer 
is needed or not depends on the kind of application and how the transaction of points 


is interleaved with the outer application. If the kind of application ensures that the 


2 


Our implementation (cp. Chapter 9) clearly demonstrates that even low-end smartphones have sufficient compu- 


tational power to run our protocol. 


22 


2.2 Main Tasks 


transaction of points has successfully terminated before users gain whatever benefit 
is traded in exchange, then a violation enforcer is probably not needed. However, if 
the kind of application is such that users may trick the PoS (or operator) to grant them 
access to the application-specific benefit before points have been exchanged, then a 
violation enforcer might be required in order to re-establish equity. See Section 2.3 and 


in particular Section 2.3.3 for an example. 


2.2 Main Tasks 


In the following, we sketch the main tasks of the system to foster a better understanding of the 
life cycle of the system. 

The term “task” has no precise definition. Also, it seems very difficult to give a formal 
definition which captures the accurate meaning in all cases. On a colloquial level, a task could 
be called a protocol, but this is formally wrong as in the context of the UC-framework (cp. 
Chapter 3), the term “protocol” denotes to the whole system, i.e. a (UC-)protocol is synonymous 
to a scheme from the more traditional game-based point of view. In our sense, “task” means 
“phase” which is another term without a generally applicable, precise definition but commonly 
used in the literature. For example, a commitment protocol (aka scheme) consists of a commit- 
ment phase and an unveil phase, or an encryption scheme’ consists of an encryption phase and 
a decryption phase. Here, we intentionally coined the term “task” and avoid the word “phase” 
as the latter suggests a predefined order/number of executions which is something we do not 


want to stipulate. An informal definition is 


Definition 2.1 (Task (informal)) Within a cryptographic protocol or scheme, a task is an 
interaction between a fixed subset of parties, which is bounded, i.e. has a defined starting and 
termination point, and which can be given some semantic interpretation. The subset of parties can 


also encompass only one single party. 


For example, the issuance of a wallet is a task. Figure 2.1 provides an overview of the most 
important tasks. A detailed description that also includes all tasks can be found in Chapter 4. 
Remember, that we tentatively concentrate on a specific embodiment that keeps the deposi- 


tion and disbursement of points separated in two tasks that also exhibit different features. 


Party Registration In order to participate in the system, all parties (users, PoSes, operator, 


etc.) must first create a public key and publish it. The public key is used to identify a party in 


* In the context of encryption the term “protocol” instead of scheme is rarely used, as encryption is assumed to be 


non-interactive. 
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Detect Double-Spending 


PoS Certify POS N 
(Point 2 f-Sale) ERS operator «Bast all Dispute Resolver 


Issue 
Wallet 


Disburse 


Prove Participation 
User |«— — — — ———| Violation Enforcer 


Figure 2.1: The P5C System Model 


the system and is assumed to be bound to the party's (physical) identity such as a passport 
number, social security number, companies' register number etc. This is done once and makes 
the party accountable in case they cheat. For the majority of parties, namely users and PoSes, 


the operator can act as the registration authority. Details are discussed later on. 


Wallet Issuing The operator issues wallets to users. A wallet is bound to the user's key and 
a set of user attributes (discussed later on). The wallet is used to deposit and/or disburse points, 
stores the accumulated balance and thus constitutes the essential object to participate in the 


system. 


Point-of-Sale Certification In order to be able to manipulate wallets in the scope of Deposit 
or Disburse each PoS needs a certificate that is signed by the operator. This certificate also 


contains a set of PoS attributes (discussed later on). 


Deposition This task is executed between a user and an (offline) PoS to deposit points on the 
user’s wallet. The user is always anonymous and the previous balance of the wallet remains 
secret. The value to be added may depend on publicly verifiable factors from outside the 
protocol (e.g. the good that is traded, the current time of day, ...) as well as a combination of 
the user’s, the current and previous PoS’ attributes. Please note, that the operator can also 
play the role of a PoS as the operator can use a self-signed PoS-certificate. To put it in another 
way, the operator delegates some of its capabilities to manipulate a wallet to PoSes by issuing 


certificates. 


Disbursement This task complements Deposit to enable users to disburse points. Disburse 


is not a mere “inverse” of Deposit, but has some distinct properties that set it apart from 
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Deposit. The concrete changes depend on the application. For most parts of this thesis, Deposit 
is executed between a user and the operator (instead of a PoS), the previous balance is unveiled 
(instead of being kept secret), and users are identified. Also, users do not receive an updated 
wallet (with a lower balance), but wallets are invalidated. However, users can obtain a new 
wallet by rerunning IssueWallet afterwards. A discussion why Disburse differs from Deposit 


is given in Section 2.3. There, also other variants of Disburse are presented. 


Double-Spending Detection As the system is an offline scheme, malicious users might 
re-use an old state of their wallet instead of the most recent one. In other words, malicious 
users are not directly detained from rewinding to a previous, more expedient snapshot of 
their wallet and thus commit double-spending. To elude this problem IssueWallet, Deposit 
and Disburse generate double-spending tags that are eventually collected by the operator. The 
operator periodically runs DetectDS on its database to find pairs of matching double-spending 


tags and to identify fraudulent users. 


Wallet Blacklisting With the help of the trusted dispute resolver, the operator is able to 
blacklist users. We assume that the dispute resolver convinces itself that either the user is 
fraudulent (e.g. by validating a proof of double-spending) or that the user has volunteered to 
be blacklisted (e.g. due to a lost wallet) out-of-band, before the dispute resolver consents to 


blacklist a user. 


Prove of Participation In special scenarios that include a violation enforcer it might be 
necessary that users are able to prove their participation in a specific execution of Deposit 


without unveiling their complete internal state. See Section 2.3.3 for such a scenario. 


2.3 Applications 


Before we proceed to further describe the scenario and eventually formally define the system, 
we take an excursion and bring forward some applications of anonymous point collection. 
Although many details of P5C are still left unspecified, we deem this necessary, as many of 
the functional features and their security properties are inspired from practical requirements. 
Hence, some definitions can only be understood with the “right” application in mind. In the 
following, we sketch important aspects when applying P5C in some selected applications. From 
a high-level perspective, applying P5C to these applications seems mostly straightforward. 


Nonetheless, there are some technical subtleties that needs to be considered: 


* The representation of integers values in a finite group and the connected problem of over-/ 


underflows or wraparounds. This results into the asymmetry of Deposit vs. Disburse 
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* Depending on the application users need to be forced to actually run Deposit or Disburse, 


if doing so is not for their benefit despite the fact that they are anonymous. 


Before we discuss some concrete applications and how the tasks of P5C are specifically used, 
we elaborate more on the asymmetry of Deposit vs. Disburse. First, we pin down the precise 


meaning of two colloquial terms in our context. 
Definition 2.2 (Price, Balance) 


(1) The price denotes the value of a single transaction, i.e. the amount of points that are 
deposited to or disbursed from a wallet in a single invocation of the tasks Deposit or 
Disburse. We use the term price for positive and negative values. The term shall not imply 
whether the transaction is beneficial for the user or not. Also, even if a price is specified as 
positive or negative, the sign shall not have an inherent signification. This is solely left to 


the application-specific interpretation of the term point. 


(2) Thebalance is the amount of points that are stored in a wallet. The balance is the accumulated 


sum over the prices of all transactions that have been conducted with the wallet. 


In P5C the price and the balance are both encoded as elements of Z, with p being the prime- 
order of the used elliptic curve. An encoding of integers from Z in Z only makes sense relative 
to a fixed representation of Z,. Two obvious representations are Z, = {0,...,p — 1} C Z or 
Zy = 22, E USES P C Z. This poses the well-known problem of wraparounds and over-/ 
underflows. We use the terms in the following meaning. 


Definition 2.3 (Over-/Underflow, Wraparounds (informal)) 


; p-1 p-1 
(1) If we have fixed the representation rx iol co 


b < = orb < p — 1 resp. and add a price p > 0 such that for the resulting balance 
b’=b+p> EL or > p — 1 holds, resp., we call this an overflow. 


| or (0,...,p — 1} and have a balance 


(2) If we have fixed the representation 22, Ae Le >) and have a balance b > -2 and 


subtract a price p > 0 such that b’ =b= p< - holds, we call this an underflow. 


(3) If we have fixed the representation {0,...,p — 1} and have a balance b > 0 and subtract a 
price p > 0 such that b’ = b — p <0 holds, we call this a wraparound. 


Shortly, for the scope of this thesis, an over-/underflow denotes an unintended change of 
sign due to passing an interval limit in the magnitude of p, while a wraparound denotes an 
unintended change of sign due to passing the interval limit at zero. 

For a minimum of 80 Bit of security, p is a prime in the magnitude of 2?*. For most appli- 


cations a wallet typically starts with a balance of zero. If we assume that the price of each 
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transaction can be bounded by some reasonable value and there are only polynomially many 
transactions, then the event of an over-/underflow can be safely ignored. For example, if a 
point represents one cent, then a wallet has to conduct transactions with a total worth of 10” € 
before an over-/underflow happens. Hence, we do not consider any special precautions against 


over-/underflows. However, depending on the application, wraparounds might be a concern. 


Surely, the trivial scenario is an application which allows arbitrary transactions in both 


directions without giving any importance to the sign of the balance of a wallet as long as the 
p-1 

en 
deposition and disbursement of points can be unified in the same task without further checks. 


sign is correct. In this case, the representation Zy = {- Oiss | is the right choice and 


But for most application the range of acceptable balances is bounded at one side. For 
example, users must not disburse more points than they have previously deposited and thereby 
unnoticeable pile debt. In this case there is one “safe” direction leading away from the bound 
and one "unsafe" direction that needs some more precautions. This yields an asymmetry which 
is reflected by the two distinct tasks Deposit and Disburse. In the following we always use 
Deposit for the "safe" direction and Disburse for the "unsafe" direction. We deposit points by 


addition of positive values and disburse points by subtraction of positive values. 


The task Deposit is conceptionally simpler and provides a very high level of secrecy. As 
Deposit represents the "safe" direction, a user always remains anonymous and the previous 


balance of the used wallet is never unveiled, when depositing points on the wallet. 


The task Disburse must deal with potential wraparounds. In its simplest variant Disburse 
unveils the current balance of the wallet to the PoS (or operator) and the PoS (or operator) 
aborts, if more points shall be disbursed than are deposited on the wallet. Obviously, this may 
infringe upon privacy and there are a variety of applications where it might be desirable not to 
reveal the current balance. To overcome this issue, the Disburse protocol could alternatively be 
extended by a range proof system such as [CCso8; CLZ12]. Range proofs are formally defined 
in Section 6.2.7 and allow the user to prove in zero-knowledge that the current balance is 
higher than the amount of disbursed points. Although there has been great progress to increase 
the efficiency of those proof systems, they considerably slow down the execution on low-end 
hardware like mobile devices (cp. Chapter 9). Depending on possible real-time restrictions 
they are not always applicable. Please note, that even range-proofs are zero-knowledge, the 
PoS (or operator) learns the statement that the wallet's balance is sufficiently high, and thus 
Disburse is "less private" than Deposit. Additionally, for some applications it might also be 
expedient or even necessary, that Disburse unveils the user's identity to the PoS/operator. In 


Sections 2.3.1 to 2.3.3 we sketch applications for all these options. 
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2.3.1 Customer Loyalty Systems 


Disburse unveils balance: yes Dispute resolver required/expedient: no 


Disburse unveils user-identity: no Violation enforcer required/expedient: no 
Disburse uses range-proof: no 


As the most basic application, we outline how P5C can be used to create a privacy-preserving 
loyalty system for customer retention. We stress that we do not aim to imitate the modern 
loyalty programs such as Payback [PAY16] or Nectar [Aim16] whose primary focus is to analyze 
their customer's behavior, train a sales-response model and sell targeted advertisement. Here, 
we present a very basic loyalty program that resembles the classic trading stamps, i.e. a system 
that realizes a “buy n, get one for free"-approach. 

The operator is the merchant or an association of several merchants who jointly run the 
loyalty system. The roles of PoSes and users are obvious. To participate in the program users 
register themselves first and then obtain a wallet. Users collect points using Deposit which is 
completely anonymous and does not unveil the current balance. In order to redeem points 
(in exchange for some benefit) users run Disburse which unveils the total balance of collected 
points. The latter ensures that users cannot redeem too many points and obtain a negative 
balance. 

In this scenario, we assume that there are many depositions prior to each disbursement. 
Hence, we assume that unveiling the balance during disbursement is a not a severe loss of 
privacy, especially if the majority of users disburse points when they have reached similar 
balances. 

In this scenario a dispute resolver is not necessarily required. Keeping the idea of trading 
stamps in the back of our mind, we do not see a good reason why blacklisting should be 
necessary. Also, an expiration date could be used and encoded into the user attributes as an 
alternative to blacklisting. In this case, wallets that are not renewed drop out of the system 
after a short time period. Of course, a dispute resolver could be used to offer users an additional 
"backup service" that allows to restore their wallets in case of a loss or similar. However, using 
our full recalculation-mechanism for this issue feels like an overdone solution. A simple backup 
of the most recent state of the wallet at the user-side would do as well. 

Also, a violation enforcer is not required. We assume users to voluntarily participate in 
Deposit, because they benefit from point collection. Vice versa, we assume users to obtain 


their reward (e.g. a free good) only after they have successfully completed Disburse. 


Simple Extensions The basic application can simply be extended in several ways: Instead 
of a single "type" of points, multiple types of points can used to differentiate between different 


types of goods. In this case a wallet does not store a single counter but a vector. Also, the user 
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attributes that are attached to a wallet could be used to distinguish between different types of 
customers and let the pricing function depend on that. On top, the user attributes can be used 


to limit the wallet's lifetime and encourage customers to collect and redeem points faster. 


2.3.2 Pre-Payment Systems 


Disburse unveils balance: no Dispute resolver required/expedient: yes 


Disburse unveils user-identity: no Violation enforcer required/expedient: no 
Disburse uses range-proof: yes 


A common application of pre-payment systems are micro-payments. First, users top up their 
wallet in exchange for real money and then successively spend their deposit. Typical examples 
are canteen systems, vending machines at work places, natatoriums or public transportation. 
Again, the roles of operator, PoSes and users are quite obvious. 

Typically, user either present their wallet once, e.g. at a vending machine, or present their 
wallet twice, e.g. at a PoS upon entering and leaving. The latter allows the price to depend on 
the duration of the stay or the distance that has been traveled. To this end, the entry-PoS sets 
the attributes of the previous PoS in the wallet, but does not disburse any price. The exit-PoS 
reads the previous PoS attributes, clears them, calculates a price that may depend on user 
attributes, previous PoS attributes as well as its own attributes and disburses the price from the 
wallet. Of course, this way a pair of transactions between entry and exit becomes linkable, but 
not with other transactions. For the role of attributes and a detailed discussion see Section 2.4. 

In a pre-payment scenario, topping up a wallet represents the "safe" direction and is realized 
by Deposit. As inSection 2.3.1 spending points is the "unsafe" direction and realized by Disburse. 
But contrary to the previous example, a single Deposit transaction that is privacy-preserving 
per default is followed by a (long) sequence of Disburse transactions. Hence, unveiling the 
previous balance during each Disburse to vouch sufficient funds might allow to link individual 
transactions. Especially, if there is a small and fixed set of admissible prices and fractional 
balances. A more privacy-friendly solution are so-called range proofs that show in zero- 
knowledge that the previous balance is higher than the price to be withdrawn. 

Including a dispute resolver into this scenario is at least useful, could foster the acceptance 
of an anonymous payment system or might even by required by legal regulations. Typically, 
the PoSes are unmanned turnstiles or similar physical barriers. In case a user has already 
lost points, i.e. Disburse completed successfully, but the barrier fails to open, a dispute can 
usually not be settled on the spot. Instead, users simply try a second time (at a different 
turnstile), provisionally volunteer to pay twice and file a claim afterwards. Here, a recalculation 


mechanism that selective lifts the anonymity of the questionable transactions is expedient. Also, 
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a lost wallet can be blacklisted such that a potential finder cannot use it and the legitimated 
owner can be compensated for the remaining balance. 

A violation enforcer is not required. As in Section 2.3.1 user will likely not prematurely abort 
Deposit, because they (physically) paid for the price to be deposited. In case of Disburse, the 
vending machine or turnstile physically ensures that access is only granted after the price has 


successfully been withdrawn. 


2.3.53 Post-Payment Systems 


Disburse unveils balance: yes Dispute resolver required/expedient: yes 


Disburse unveils user-identity: yes Violation enforcer required/expedient: yes 
Disburse uses range-proof: no 


A post-payment system is not simply the inversion of a pre-payment system as presented in 
the previous section. Post-payment systems are preferable over pre-payment system, if a high 
throughput of users is vital. In these scenarios, the speed of admissions must not drop either 
because users have simply forgotten to sufficiently top up their balance (as it might be the case 
in a pre-payment system) or because a transaction fails for other reasons. In some scenarios 
it might be even impossible or undesirable to prevent users from access to the good/service 
without paying first. In order to make this example more interesting and set it further apart 
from a pre-payment system, we focus on this special kind of scenarios. 

This being said, a post-payment system differs from a pre-payment system in two aspects 
(despite the fact that the meaning of points is “inverted”). Firstly, users must be enforced to 
eventual clear their collected debt. Opposed to the previous examples, there is no inherent 
incentive for the users to do so. Secondly, “free-riders” who are able to gain admission at no 
charge must be pursued after the fact. Both aspects conflict with the anonymity of users. 

In order to solve the first issue, a limited lifetime is encoded into a user's wallet as part of 
the user attributes. We assume that the system uses fixed billing periods, e.g. monthly billing 
periods, which are the same for all users. Prior to the beginning of a billing period, users obtain 
a fresh wallet from the operator using IssueWallet. As IssueWallet is identifying, the operator 
records which user owns a wallet for a particular billing period. Within a billing period, users 
collect debt at PoSes using Deposit. Please note, that adding points to the wallet actually means 
increasing the owed debt. Again, deposition is the "safe" direction, does not unveil the previous 
balance and is non-identifying. At the end of a billing period, users are requested to clear their 
owed debt by running Disburse with the operator. In this scenario, Disburse unveils the total 
balance and the user's identity such that the operator can invoice the user. As in Section 2.3.1 
we assume that the total balance sufficiently masquerades the individual Deposit transactions. 


A successful disbursement invalidates the wallet. After having cleared the owed debt (in the 
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real world using a traditional payment method), users may run IssueWallet again to obtain a 


new wallet for the next billing period. 


The dispute resolver is necessary, if users refuse to clear their last wallet and accept not to 
get issued a new one. In this case, the operator and the dispute resolver can jointly recover all 
transactions of the outstanding wallet and the operator can then pursue the debtor. Also, a 
dispute resolver is expedient for the same reasons as in Section 2.3.2, e.g. lifting privacy in case 


of a dispute or immediate blacklisting of lost or stolen wallets with the consent of the user. 


In order to pursue free-riders that refuse to collect debt, but gain access to the service 
nonetheless, the involved PoS triggers the violation enforcer which persecutes and punishes 
the free-rider, if found guilty. To this end, the violation enforcer needs to identity the user out- 
of-band. Typically, this involves taking a photo of the suspect using a camera that is mounted 
on every PoS but is owned and operated by the violation enforcer. We stress that we used 
the term “trigger” on purpose: The assume the communication between the PoS (or operator, 
resp.) and the violation enforcer to be one-way. Otherwise, a curious PoS/operator might be 
tempted to exploit the cameras in order to lift the privacy in each and every transaction. Due 
to technical limitations, it might be impossible to exactly determine which user triggered the 
camera. To settle this situation, the violation enforcer summons all users under investigation to 
run the task ProveParticipation. This task allows all innocent users to prove their participation 


in a matching Deposit task with the particular PoS. 


We illustrate the scenario using electronic toll collection (ETC) in an open-road setting as 
a concrete example. This scenario is considered by Nagel et al. [Nag+20]. In this setting the 
violation enforcer is typically a police authority or another law enforcement agency. Moreover, 
users correspond to vehicles and PoSes to toll gantries. The dispute resolver could be an NGO 
or another public authority, like the data protection authority, a court or the department of 
justice. In an open-road setting, vehicles pass through toll gantries at normal travel speed and 
are tolled in transit. Due to a variety of reasons, a vehicle might simply pass the toll gantry 
without collecting debt. In these cases, the toll gantry triggers a camera. Especially in case of 
multi-lane roads, several photos of more than one vehicle being in the range of the toll gantry 


are taken or a single photo might show several suspects driving close to each other [Kap18]. 


We like to stress two aspects: Firstly, a user only needs to participate in ProveParticipation, 
if something has failed and if the user is in the set of suspects. Secondly, we assume that all 
erroneously suspected users volunteer to run ProveParticipation. Moreover, in any case, users 
always have the option to appeal to the dispute resolver and thereby unveil its successful 
participation in a transaction at the PoS under audit. But, the dispute resolver unveils all 
transaction of a particular wallet, while a ProveParticipation only proves the participation in a 


single transaction. This means, ProveParticipation is more selective and less privacy infringing. 
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Simple Extensions ‘The user attribute can not only be used to limit the wallet’s lifetime, 
but could encode further attributes to distinguish between different classes of users as in 
Section 2.3.1. Also, the previous PoS attribute could be encoded into the wallet as in Section 2.3.2 
to realize distance-based tolling. Then, the pricing function may be dynamic and depend on 
different factors like the current time and congestion, the number of axles (recognized by 
sensors attached to the PoS), some user attributes attached to the wallet as well as some 


attributes of the previous PoS the user drove by. 


2.3.4 Further Applications and Running Prime Example 


The aforementioned examples are by far not a complete list. For example, in an anonymous 
reputation system with discrete reputation levels that correspond to intervals of reputation 
points, e.g. 0-9 corresponds to novice, 10-19 is beginner, up to 90-99 for expert, the range 
of admissible points is bounded at both sides. This peculiarity is not covered by any of the 
examples above. In [Nag+17] we sketched how this can be realized without using range-proofs 
if combined with an anonymous reputation system. Nonetheless, we deem this list a sufficient 
indication how to apply anonymous point collection to further applications. 

For the remainder of this thesis, we use the post-payment system from Section 2.3.3 as our 
prime example and baseline. The sketched post-payment system requires the most features 
(such as a violation enforcer) from all examples. This also implies that—if not stated otherwise— 
we consider a variant of Deposit that is executed between a user and the operator, unveils 
the balance and identifies the user. This variant is used to formally define anonymous point 
collection in Chapter 4 and to realize P5C in Chapter 7. Concentrating on a single variant 


keeps the presentation simpler than tedious case-by-case distinctions. 


2.4 Attributes, Pricing Function and Privacy Leakage 


Our system involves two types of attribute vectors: user attributes aq, as well as PoS attributes 
ap. User attributes are stored in the wallet and are set when the wallet is issued. PoS attributes 
are part of the PoS certificate and set when the PoS is certified. Moreover, the attributes of 
the participating PoS are written to the wallet when the wallet is issued* and when points are 
deposited or disbursed. In other words, a wallet carries the attributes of the previous PoS it 
has interacted with besides its own user attributes. As a trivial generalization the attributes of 
a PoS could be split into a "full" attribute vector that is attached to the PoS' certificate and a 
sub-vector of attributes that is carried by the wallet as the (partial) attributes of the previous 


PoS. For the ease of notation, we only consider a single vector. 


4 


In IssueWallet the operator plays the role of a PoS using a self-signed PoS certificate 
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2.4 Attributes, Pricing Function and Privacy Leakage 


We do not stipulate which kind of attributes or how many of them are used. Those 
details depend on the concrete pricing model of the application with a pricing function 
P= forice(Gup Ap, es aux) depending on the user attributes, the current and previous PoS 
attributes ap, ab sY and auxiliary, publicly verifiable input aux (e.g., time of day, weather con- 
ditions, ...). However, we expect that for most scenarios very little information needs to be 
encoded into these attributes. Typical examples have been sketched in Sections 2.3.1 to 2.3.3. 
For instance, limiting the validity of a wallet is quite common. Either to animate users to 
increase the volume of sales or—if points on a wallet represent some kind of debt—to actually 
force users to eventually clear their debt. Clearly, for privacy reasons, unique expiration dates 
in attributes need to be avoided. In case of unattended PoSes, one might want PoSes to also 
have an expiration date which is periodically renewed and encoded as a PoS attribute. As the 
secrets of a PoS allow to tamper with a wallet’s balance, such an expiration date mitigates the 
damage of a stolen or compromised PoS. Also pricing models that are based on a distance 
between two PoSes or the duration of admission can be realized by using PoS attributes to 
distinguish between entry and exit PoSes? 

Obviously, the concrete content of the attributes affects the “level” of user privacy in an 
instantiation of our system. In case of our running prime example (cf. Sections 2.3.3 and 2.3.4) 


the goal is to provide provable privacy up to what can be possibly be deduced by 


(1) an operator/PoS who explicitly learns those attributes as part of its input to the pricing 


function fprice and 


(2) an operator who explicitly learns the balance b of a user at the end when points are 


disbursed. 


Our framework guarantees that protocol runs of honest users do not leak anything (useful) 
beyond that (cp. Chapter 5). In Section 5.3, we analyze the impact of these attributes on the 
privacy leakage of our system in more detail. 

Item (1) of the previous paragraph already indicates that in our design of an anonymous 
point collection system the price of a transaction is determined by the PoS‘ that unilaterally 
evaluates the pricing function fprice and thus needs to know the attributes of the user and 
previously visited PoS. This design might seem not as "ideal" as it could be and comes with 
two obvious cutbacks at first glance. It may needlessly infringe upon the user's privacy and 
the PoS could deviate from the "right" price. This has been an intentional design decision with 


respect to real-world applicability. 


^ Inthis way, the entry and exit point can be linked. Still, our system ensures that the user is anonymous and 


multiple entry/exit pairs are unlinkable. 


* In the next few lines, we only use the term PoS, but what is said also applies to the operator. 
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Please remember, that the PoS and user must efficiently evaluate the pricing function fprice 
themselves in the real implementation without the help of a third party due to offline capabilities. 
Ultimately, this boils down to two options: Either the pricing function is evaluated in the clear 
which implies that both parties learn their mutual inputs, or the PoS and user run some sort of 
secure two-party computation (2PC). 

Depending on the complexity of the pricing function general 2PC techniques might be too 
inefficient to meet the real-time requirements of most applications, especially if low-end devices 
like smart phones are involved. Note that it does not suffice to pass the attributes as input to the 
2PC and merely evaluate the pricing function, but the 2PC must also ensure that the “correct” 
inputs are used, i.e. those that are attached to the wallet and the PoS certificate. Skipping ahead 
to the implementation, this would imply—among other things—to validate signatures inside 
of 2PC. Of course, there might be extremely simple pricing functions that also exhibit some 
kind of “structural compatibility” with the building blocks of an instantiation of our scheme 
such that one can abstain from general 2PC technique but resort to tailored techniques that 
nicely interplay with the other building blocks in a white-box fashion. However, these cases 
are presumably rare. Also, evaluating the pricing function with 2PC and keeping the inputs 
secret has only a beneficial impact on the achieved “level” of privacy, if the pricing function is 
sufficiently intricate. If the pricing function allows to infer the inputs from the price, using 
2PC yields no benefits. In summary, we conjecture that most application fall into one of the 


following three categories: 


(1) The pricing function is extremely simple (e.g. a constant admission fee), especially it 
does not depend on user attributes. In this case the user attributes are trivial, too, (e.g. a 


zero-length vector) and handing over aq, to the PoS does not harm privacy. 


(2) The pricing function is moderately simple and only depends on a few user attributes 
such that it is suitable for tailor-made 2PC in principle. For example, there are different, 
but fixed prices for a finite set of user classes (e.g. “newcomers”, “regulars”, “patrons”). 
In this case 2PC is of no practical benefit, because the resulting price unveils the original 


input anyway. 


(3) The pricing function is complex, depends on various attributes and especially is not 
injective, i.e. maps large sets of different attribute values to the same price. In this case, 
2PC could increase the “practically” achieved level of privacy, but 2PC is typically too 


inefficient. 


In conclusion, we are convinced that evaluating the pricing function in the clear, is the right 


choice. 
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2.5 Handling of Aborts 


Also, with the timing-constraints of typical applications in mind, we assume that users 
preliminarily accept any price willingly in order to proceed and (in case of a dispute) file an 
out-of-band claim later. To this end, fpc outputs all relevant information about the transaction 
to the users. This enables them to check the price themselves and to appeal afterwards if the 
wrong amount of points is deposited. In the real world, this detectability will deter PoSes from 
manipulation. 

In order to allow users to assess the privacy of a particular instantiation of our framework, 
we recommend that all attributes, all possible values for those attributes and how they are 
assigned, as well as the pricing function are fixed in advance and public. In this way, the 
operator is also discouraged from running trivial attacks by tampering with an individual’s 
attribute values (e.g., by assigning a billing period value not assigned to any other user). To this 
end, a user needs to check if the assigned attribute values appear reasonable. Such checks could 
also be conducted (at random) by a regulatory authority or often also automatically by the 
user's device. Likewise, a PoS could try to break the privacy of a user by charging a peculiar 
price. However, these "attacks" cannot be ruled out by cryptographic means but are immanent 
to the application. Again, we assume that watchful users file a claim in such a case which may 


lead to an audit. 


2.5 Handling of Aborts 


To enable offline capabilities IssueWallet, Deposit and Disburse all generate double-spending 
tags which are eventually collected by the operator. If the operator encounters a pair of 
matching double-spending tags the associated, fraudulent user is identified. If Deposit is 
aborted after this double-spending tag has been generated but before the user has received a 
new wallet state, the user is left with an already used wallet state. In this case users have two 
options: (1) Either they re-use this wallet state in the next transaction and thus deliberately 
commit double-spending, or (2) they contact the operator to be issued a new wallet. In both 
cases the user is identified. Thus, an abort during Deposit allows to partly lift privacy. We stress 
two points here: Firstly, privacy is only lifted for one particular transaction. All remaining 
past and future transactions are unaffected. Secondly, privacy-under-abort is a well-known 
open problem and not specific to our system. 

We expect unintentional aborts to only occur infrequently and hence result in an acceptable 


level of privacy infringement. Furthermore, the operator and PoSes have very little reason 


Without perfect fair exchange, either the double-spending tag is created before the users obtain a new, valid state 
of their wallet or vice versa. In the first case, it is always possible to abort such that users are left with an invalid 
wallet. In the second case, a malicious user could purposely abort before a double-spending tag is generated. This 
would foil double-spending detection altogether. 
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to abort purposely: They cannot target specific users, as the user is completely anonymous 
during Deposit. Only after an PoS aborts will the operator learn which user’s privacy they 
have infringed upon. Hence, PoSes would have to abort a substantial amount of transactions 
in order to gain useful information. Doing so would draw attention, certainly lead to an audit 
of the operator and thus be contrary to their business interests. 

In the opposite direction, the system or the surrounding application must ensure that a user 


does not benefit from an abort: 


(1) A user has an intrinsic benefit to complete an advantageous transaction, e.g. top up a 


pre-payment card, gain more reputation points, etc. 


(2) A user is (physically) prevented from gaining an extrinsic benefit before a disadvan- 
tageous transaction has successfully completed, e.g. by a turnstile, vending machine, 


etc. 
(3) A user is externally identified by a violation enforcer and prosecuted. 


In any case, if a user aborts too late, they are identified by the double-spending mechanism. 
Aborts of any task other than Deposit are trivially handled by repetition, as the involved 


parties are non-anonymous anyway. In the remainder of this thesis we ignore aborts. 


2.6 Desired Properties 


With the applications from Section 2.3 at the back of our mind, the following list summarizes 
some exemplary, informal and desirable high-level properties that one would reasonably expect 
from anonymous point collection. These properties inspire the eventual definition of the ideal 
functionality in Chapter 4. Note that the ideal functionality (and not this list) is meant to 
formally conceive the security of our proposed protocol. Nonetheless, this list may help to 
better understand the scenario and concludes this chapter. In Chapter 5 we demonstrate how 
these high-level goals are reflected in the ideal functionality. We stress that some of these 
goals are not immediately achieved by the ideal functionality alone (for example property (P5)), 
but only make sense in combination with the outer application. For these cases, our system 


exports appropriate interfaces to enable the outer application to implement this feature. 
(P1) Owner-binding: A user may only use a wallet legitimately issued to him. 


(P2) Attribute-binding: A user cannot pretend a wallet to bear other attributes than those that 


were legitimately attached to it; be it user attributes or be it previous PoS attributes. 


(P3) Balance-binding: A user cannot unveil a different balance (in Disburse) than the amount 


added to the wallet unless the user has committed double-spending. 
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(P4) 


(P5) 


(P6) 


(P7) 


(P8) 


(Po) 


(P10) 


(P11) 


Double-spending Detection: If a user reuses an old state of a wallet, the user will be 
identified. 


Participation Enforcement: If a user fails to participate in Deposit, he will be identified. 


Blacklisting: The operator is able—with a hint from the dispute resolver—to efficiently 


blacklist wallets of individual users. 


Accountability: The operator is able—with a hint from the dispute resolver—to efficiently 
trace the transactions of an individual user. This allows to determine the actual balance 
of a double-spender. Also, in a dispute, a user may request a detailed invoice listing of 


the visited PoSes the associated transactions. 


Renegade Expulsion: As the secrets of an PoS allow to tamper with a wallet’s balance, the 


system supports a mechanism to mitigate the financial loss due to a compromised PoS. 


Unlinkability: If user attributes and (previous) PoS attributes are ignored, a collusion of 
operator and PoSes may not be able to link a set of IssueWallet, Deposit and Disburse 
transactions of an honest user given that the user is neither blacklisted nor has committed 
double-spending. More precisely, IssueWallet, Deposit and Disburse do not reveal any 
information (except for user attributes, PoS attributes and the final balance in case of 


Disburse) that may help in linking transactions. 


Participation Provability: ProveParticipation enables the violation enforcer to deanon- 
ymize a single transaction of an honest user in case of an incident. The remaining 


transactions stay unlinkable. 


Protection Against False Accusation: The user is protected against false accusation of 


having committed double-spending (cp. (P4)). 
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We model P5C within the UC-framework by Canetti [Canoı], which is a simulation-based 
security notion. The UC-framework carries forward the tradition of simulation-based security 
definitions for general protocols in an arbitrary context ([GMW 86; Beag2; MRo2 ]). 
Simulation-based security notions come with the great advantage over other kinds of security 
notion that they usually explicate the achieved “level” of security very clearly. This stands in 
contrast with game-based definitions, where security is expressed by a number of games. A 
set of individual security games always bears the inherent danger that an important aspect is 
overlooked, thus not captured by any game and thereby inadvertently claiming an insecure 
system as secure. Guarantees expressed in a simulation-based notion usually have more 
evident semantics, obtained from directly considering how a protocol is used, rather than a 
hypothetical interaction of an adversary with a simplified game that encodes excluded attacks. 
More importantly, simulation-based security notions are also very good at making explicit 


what cannot be achieved. 


The great advancement of the UC-framework over previous work is its general composition 
theorem. Security under (universal) composition is a very strong notion. The guarantees are 
provided even if a protocol is executed in an arbitrary environment, alongside other protocols. 
Moreover, composable frameworks facilitate modularity. One can define components with 
clean abstraction boundaries and use their idealized versions in a higher-level protocol. The 
overall security of the composed protocol follows from the composition theorem. 

After its first publication the UC-framework and the independent, but conceptionally very 
similar work by Pfigmann and Waidner [PWo1] have spawned a long series of further research 
on security definitions. Besides major revisions [Canoo; Cano5; Canı3; Can18] extended 
frameworks either for generalized settings or for broadened problem definitions [Can+07; 
CVı2; CRo3] were proposed. Pass [Paso3], Prabhakaran and Sahai [PSo4], Barak and Sahai 
[BSo5], Canetti, Lin, and Pass [CLP10], and Broadnax et al. [Bro+17] analyzed relaxations of 
the UC-framework that require less assumptions but still yields a meaningful, (somewhat) 
composable security notion. Kat; [Kato7] investigated alternative setup assumptions. Moreover, 
UC-compatible security definitions for most cryptographic primitives have been formalized 


(see [Canos] for an overview). There are other conceptionally very similar frameworks that also 
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come with a general composition theorem [BP Wog4; Küso6; HS15; Mauz1; MR11]. Nonetheless, 
the UC-framework remains the de-facto standard to prove security of a protocol. 

This chapter is organized as follows. In Section 3.1 we give a condense overview and line 
out the “big” picture. Sections 3.2 and 3.3 proceed with a formal definition. This formal 
definition is based on a compilation of [Cano5; Cani3] with some backported fixes from 
[Can18; HS15]. Although we slightly deviate from the original UC framework and also clarify 
some aspects where the original framework is ambiguous, these details are not crucial and 
thus the Sections 3.2 and 3.3 do not contain new information for readers who are familiar 
with the UC framework. Hence, the expert reader may skip these sections and proceed with 
Section 3.4. Nonetheless, we deem a formal foundation necessary, in order to soundly discuss 
the communication model. Shortly stated, the original UC-framework uses—what we call— 
“identity-based” addressing to send messages between parties. Clearly, this foils any attempt 
to define a protocol with anonymous parties right on the definitional level. We clarify this 
and related issues in Section 3.4. Also, we define some custom ideal functionalities for secure 
and anonymous communication in Section 3.4. This chapter concludes with Section 3.5 on 
setup assumptions, some well-known functionalities from the literature and implicit writing 


conventions for ideal functionalities. 


331 Overview on the UC Framework 


In the UC-framework, an ideal functionality F (acting as T TP) is defined that plainly solves 
the problem at hand in a secure and privacy-preserving manner. A protocol zis said to be a 
(secure) realization of this ideal functionality F if no PPT-machine Z, called the environment, can 
distinguish between two experiments: the real experiment (running 1) and the ideal experiment 
(using F). 

In the real experiment, Z interacts with parties running the actual protocol z and is supported 
by a real adversary A. The environment Z specifies the input of the honest parties, receives 
their output and determines the overall course of action. The adversary A is instructed by Z 
and represents Z’s interface to the network, e.g., A reports all messages generated by any party 
to Z and can manipulate, reroute, inject and/or suppress messages on Z’s order. Moreover, Z 
may instruct A to corrupt parties. In this case, A takes over the role of the corrupted party, 
reports its internal state to Z and from then on may arbitrarily deviate from the protocol z in 
the name of the corrupted party as requested by Z. 

In the ideal experiment, on the other hand, the protocol parties are mere dummies that pass 
their input to a trusted third party Fand hand over F's output as their own output. The ideal 
functionality 7 executes the task at hand in a trustworthy manner and is incorruptible. The 


real adversary A is replaced by a simulator S. The simulator must mimic the behavior of 
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A, e.g., simulate appropriate network messages (there are no network messages in the ideal 
experiment), and come up with a convincing internal state for corrupted parties (dummy 
parties do not have an internal state). 

If no environment Z can tell executions of the real and the ideal experiment apart, then 
any successful attack existing in the real experiment would also exist in the ideal experiment. 
Therefore, the real protocol 7 guarantees the same level of security as the (inherently secure) 
ideal functionality F. 

Regarding privacy, the situation in UC is somewhat unsatisfying. As far as input privacy is 
concerned, the UC framework perfectly suitable. Note that all parties (incl. the simulator) use 
the ideal functionality as a black-box and only know what it explicitly allows them to know 
as part of their prescribed output. The output to the simulator is called leakage. This makes 
UC suitable to reason about input privacy in a very nice way. As no additional information is 
unveiled, the achieved level of input privacy can directly be deduced from the defined output of 
the ideal functionality. In other words, the privacy assessment can be conducted onto the ideal 
functionality and is completely decoupled from the analysis of the protocol implementation. 
The proof of indistinguishability asserts that any secure realization of the functionality provides 
the same level of privacy. 

With respect to sender privacy—or anonymity—the UC framework is somewhat flubbed. 
Strictly speaking, it is impossible to achieve anonymity in UC due to the way how message 
routing and transportation is formally defined in [Canoo; Can13; Can18]. If a party wants to 
send a message to another party, the actual message has to be prefixed with the sender's and 
receiver's identity which are used as addressing information. The message is then handed over 
to the adversary for delivery who may alter the message (including the addressing information) 
unless authenticated channels are assumed. But even in the plain model without authenticated 
channels the addressing information still exists as a prefix to the message and thus is learned 
by the receiver. We cope with this issue by unhinging the (implicit) message transportation 
from the UC-framework, defining a couple of ideal functionalities and thereby making message 


transportation explicit. 


3.2 The Formal Model of Computation 


In UC, the basic entity of computation is a Turing machine (TM). Conceptionally, UC distin- 
guishes between interactive Turing machines (ITMs) and interactive Turing machine instances 
(ITIs). An ITM is an intangible and static object, while an ITI is a concrete instantiation of an 
ITM. The ITM defines all common characteristics, especially the code. An ITI is the runnable 
realization of an ITM and has a well-defined internal state (given by the content of its tapes, 


see below). 
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Definition 3.1 (Interactive Turing Machine (ITM)) An interactive Turing machine is a 
probabilistic Turing machine with the following properties. Besides its usual working tape, it has 


the following tapes: 


* An identity tape: This tape contains two strings prg and id. prg is the code of the TM and 
id the identity. id — (prg, id) is called the extended identity. This tape is read-only. 


* An outgoing message tape: This tape contains a sequence of all generated message of the 
form m = (id 


This tape represents the outbox for messages that are supposed to be sent to other parties 


snd» idycy, m). m is called the (actual) message and m the extended message. 


over the network. 


* An output tape: Syntactically, identical to the outgoing message tape. This tape represents 
the outbox for messages that are locally passed to other ITI’s within the same party. 
* Two externally writable tapes: 
(1) An incoming message tape 
(2) An input tape 
They are the counterparts to the outgoing message tape and output tape, resp. They serve as 


inboxes and are non-writable with respect to the possessing ITM. 


* A random tape A read-only tape that contains a uniformly drawn bit string of sufficient 


length. We assume that this tape cannot be exhausted. 
An ITM has two additional instructions: 


* write-external: The ITM writes a new message on its outgoing message tape or output tape 


and halts. The destination tape and the message are parameters of the instruction. 


* read-next: The ITM reads the next, unread message from the incoming message tape or 


input tape. The source tape is specified as a parameter of the instruction. 


Please note, that an ITM supports two different halt states: a) The usual halt state identical 
to an ordinary TM. The ITM transits into this halt state if prescribed by its program. In this 
case the ITM cannot be activated again, but is “dead”. b) A temporary halt state adopted by the 


ITM due to a write-external. In this state, the ITM "sleeps" until it is activated again. 


Definition 3.2 (Interactive Turing Machine Instance (ITI)) An instance M of an ITM is 
defined by its extended identity id — (prg, id). 
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The number and names of the different tapes related to messaging have evolved over the 
different revisions of UC [Canoo; Cano5; Can13; Can18]. For Definition 3.1 we chose a variant 
that we believe to be the “Best-Of”. The number of tapes is the same as in [Canoo]. Here, 
we have a pair of two tapes for passing local data (input/output tape) and a pair of tapes for 
network messaging (incoming/outgoing message tape). We slightly changed their names such 
that their pairwise association becomes more evident. 

We now define a system of ITIs. The following definition can be thought of as a set of rules 
how ITIs are allowed to interact with each other. To increase the flexibility and to enable 
different models of computation [Can13; Can18] takes a two-step approach and introduces a 
so-called global control function as an intermediate step. To put it simple, this global control 
function is a bit-valued function (0, 1]* — {0,1} that determines whether a write-external- 
command is allowed (or not) depending on the content of the tapes of the involved TMs. In 
the second step, [Can13; Can18] concretely instantiates this global control function. However, 
the Universal Composition Theorem (implicitly) assumes that the global control function is 
exactly instantiated as is. We do not define such a function separately but incorporate it into 
the definition of a system of ITIs. 


Moreover, we push forward a definition on the identification of ITIs. 


Definition 3.3 (Party Identifier (PID), Session Identifier (SID)) We assume that the iden- 
tity string of an ITI is structured as id — (pid, sid). The first part is called the party identifier (PID) 
and the second part is called session identifier (SID) of the ITI. 


The reason for this convention becomes clear after the next definition. The following definition 
appears to be very long-winded and cumbersome. An intuitive explanation that makes this 


definition actually trivial follows below. 


Definition 3.4 (System of Interactive Turing Machine Instances) A system 6 = (Z, A) 
of ITIs is defined by two ITIs Z and A that generate the system. Z is called the initial ITI or the 
environment. A is called the adversary. More ITIs M € G are invoked while the system is executed. 
If an ITI M invokes (i.e. creates) a new ITI M', M is called the direct parent of M’ and M' is 
called the direct subsidiary of M. In the following let m = (id 4, id, y, m) denote the extended 
message that has been passed as the parameter to write-external. Also let id,.q = Cprg gna Id sna? 
sid nq) denote the extended ID, the code, the ID, the PID and SID of the 


claimed sender. Likewise, id, = (PIE rey: rev) and idyev = (pid cy» Sidrey) denote the same 


snd? 


and id, = (pid... 4. 
for the claimed receiver. Moreover, id — (prg, id) and id — (pid, sid) belong to the true sender 
and id. = (prg’, id’) and id’ = (pid’, sid’) belong to the true receiver. Beware, that the claimed 
sender/receiver does not necessarily equal the true sender/receiver. If we say the execution fails, 
the system © immediately holds and outputs a special failure symbol. Then, the execution of © 


on input x is governed by the following rules: 
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* Z is activated with x on its input tape 
e G halts, if Z halts finally; the output of © is the output of Z. 


* If Z calls write-external: 
(1) If Z uses the outgoing message tape, the execution fails. 
(2) If Z uses the output tape: 
(a) If pid ad + Pid,., holds, the execution fails. 
(b) If the destination ITI M’ with id’ = id,., does not exist, a new ITI M’ with 
id = (prg’, id’) is invoked and m is written on its input tape. The new ITI MW’ 
becomes a direct subsidiary of Z and Z its direct parent. 
(c) If the destination ITI M’ with id’ = idey exists: 
(i) If prg’ + prg,.., the execution fails. 
(ii) If id’ is not a direct subsidiary of Z, the execution fails. 


(iii) If id,,q does not equal the extended identity that has been used by Z as 
the sender’s identity when write-external was called the first time for this 


particular receiver, the execution fails. 


(iv) Else, m is written on the input tape of M’. 


e If A calls write-external: 


(1) If A uses the outgoing message tape, and the destination ITI M’ with id’ = id yo, 


exists, m is written onto its incoming message tape, else the execution fails. 
(2) If A uses the output tape and id, is the identity of Z, m is written on the input tape 
of Z, else the execution fails. 
e If any M € 6\ {Z, A} calls write-external: 


(1) If M uses the outgoing message tape and id pq = id and sid nq = Sidyey holds, then 


m is written onto the incoming message tape of A, the execution fails. 
(2) If M uses the output tape: 
(a) If id,,q + id or pid nd + Pid cy holds, the execution fails. 


(b) If the destination ITI M’ with id’ = id,., does not exist, a new ITI M’ with 
id = (prg’, id’) is invoked and m is written on its input tape. The new ITI M’ 
becomes a direct subsidiary of M and M its direct parent. 


(c) If the destination ITI M’ with id’ = idyey exists: 
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(i) If prg’ + Prg cy the execution fails. 
(ii) If M’ is not a direct subsidiary nor a direct parent of M, the execution fails. 


(iii) Else, m is written on the input tape of the destination ITI. If id,., is the 
extended identity of Z that has been used by Z to invoke this ITI, then the 
code field of the claimed sender is erased before the message is passed onto 


Z’s input tape, i.e id pq = (L, idyoy). 


* If write-external has successfully been called, the senders halts and the receiver is activated 


next. 
e If an ITI halts without having called write-external, the environment Z is activated again. 


We discuss this definition on two counts: Firstly, we give a graphical explanation that makes the 
definition more memorable, secondly, we highlight the differences to the original definition(s). 

We start with “normal” ITIs (cp. Fig. 3.1). A “normal” ITI—neither the environment nor the 
adversary—can best be depicted as a single process running on a usual physical computer. The 


subset of all ITIs that share the same PID are located on the same machine, i.e. they constitute 


Session 3 


( ) ITI — Input/Output --- Incoming/Outgoing Message 


Figure 3.1: A System of ITIs 
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a party (framed by dashed line in Fig. 3.1). Within a party the involved ITIs communicate via 
their input/output tapes; the input/output tapes must not be used for communication with ITIs 
belonging to other parties (cp. Item (2a)). This kind of communication is secret, trustworthy, 
reliable and immediate. Especially, the ITIs know each other's code (cp. Item (2c-i)). This 
models the fact that some “main process" usually knows the called “subroutine function”. 
Moreover, the caller must not lie about its own identity (cp. Item (2a)). The only exception to 
this rule affects the output of the root ITIs to the environment Z (cp. Item (2c-iii)). Here, the 
environment that initially has invoked the root ITIs and thus has determined their code prg 
has no guarantee that the ITI returning output to the environment actually runs the stipulated 
code.’ New subsidiary ITIs (e.g. “subroutine functions") are implicitly created, if they are called 
for the first time (cp. Item (2b)). Communication is only allowed along the calling graph, i.e. 


the hierarchy of ITIs within a party forms a tree (cp. Item (2c-ii)). 


While parties group ITIs *vertically", sessions group ITIs "horizontally" (cp. framed by dotted 
line in Fig. 3.1). ITIs belonging to the same session can best depicted as the different legs of a 
communication channel (e.g. the initiator and the target of a TLS connection). ITIs of the same 
session use the incoming/outgoing message tapes for communication. Again, the sender must 
not lie about its identity and is only allowed to send messages to other ITIs of the same session 
(cp. Item (1)). However, there are no security guarantees whatsoever as all incoming/outgoing 
messages are routed through the adversary A who represents an unreliable and untrustworthy 


network. 


The environment Z is the initial ITI of the whole system. It binds together all parties and 
creates their root ITIs. As its name suggests, Z constitutes the environment in which the parties 
are executed and also incorporates any other processes that run concurrently. Intuitively, Z 
represents the “mastermind” that controls all parties by purporting their input and processing 
their output. Also, Z is allowed to communicate with the adversary A via input/output, but 
must not participate in the network itself (cp. Item (1)). If Z wishes to do so, it may request A 
for that (see below). To enable Z to be the parent of root ITIs of different parties, the restrictions 
on using its input/output tape are relaxed compared to "normal" parties. The environment Z 
is allowed to impersonate different parties. If Z originally invokes the root ITI of a not yet 
existing party it must do so using the designated PID (cp. Item (2a)) of the new party. Note, that 
neither Item (2a) nor Item (2b) demand that the “claimed” extended identity id of Z as a sender 
must be Z’s true identity. However, if Z has called an ITI once, it has to do so consistently 


(Item (2c-iii)). 


1 "This detail becomes important for the definition of protocol simulation. 
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The adversary A represents the network. As such, it must not use (local) input/output except 
for the communication with Z (cp. Item (2)). Any message that is written by any ITI M onto 
its outgoing message tape is handed over to A. Although, M is not allowed to claim any other 
sender than itself, there are no restriction on how the message is handled by A. Hence, A may 
arbitrarily manipulate, reroute, inject and/or suppress messages. A may send any (extended) 
message to any incoming message tape of any (existing) ITI with no restrictions on the claimed 
sender identity (cp. Item (1)). 

Finally note that the model of asynchronous execution in UC is conceptionally very similar 
to what is called preemptive multitasking in the field of operating systems. At every point of 
the execution only a single ITI is active and the scheduling is message-driven. In other words, 


an ITI remains active until it voluntarily waives activation by passing a message to another ITI. 


Deviations from the original UC framework The above definition enforces that the 
hierarchy of ITIs belonging to the same party is a tree and ensures that passing local input/ 
output is only allowed along this hierarchy. As other aspects of the framework the concrete 
details have evolved over time and [Canos; Can13] explicitly claims? to allow arbitrary local 
communication among ITIs of the same party in order not to unnecessarily exclude certain 
models of computation. However, a non-hierarchical system of ITIs turns out to be problematic 
with respect to the composition theorem and corruption. Hofheinz and Shoup [HSı5] showed 
that the composition theorem as originally be stated in [Canoo] does not hold and therefore 
only consider trees for their own GNUC framework. To remedy this problem, Canetti [Cano5] 
introduces the concept of subroutine-respecting protocols? in a first step. In a second step, 
[Can18] additionally demands protocols to be compliant. In order to avoid these technicalities 
all together, we follow the approach of Hofheinz and Shoup [HS15] and simply restrict the 
framework to parties with a tree-like calling hierarchy. 

Moreover, Definition 3.4 clarifies that a new ITI is only allowed to be created by its parent via 
passing (local) input to it for the first time. In the original UC framework, a new ITI is created 
on-the-fly whenever a message of any kind is delivered to it, i.e. a new ITI may also be created 
by the adversary delivering an incoming (network) message to a non-existing ITI. Again, 
this flexibility raises some definitional problems. In Definition 3.4 the adversary's attempt to 
deliver an incoming (network) message to a non-existing recipient simply fails. Considering 
real computers and real programs we deem this clarification sufficient. The system of ITIs 
belonging to the same party must be created bottom-up from its root and the receiving end of 


a communication needs to be created first and then wait for incoming messages. 


?^ However, this is not reflected by the formal definition of the control function 


Subroutine-respecting protocols do not necessarily adhere to a tree-like hierarchy but must not be arbitrary 
neither. 


3 
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3.3 UC Protocols and Protocol Emulation 


After having defined the computational model in the previous section this section defines how 


to use it to model interactive computer programs and define their security through emulation. 
Definition 3.5 (Protocol, Protocol Instance) 
(1) A protocol x is an ITM running the code z. 


(2) A protocol instance of zt is a set of ITIs running x that all share the same SID but have 
pairwise different PIDs. 


In the UC framework the terms “code”, “protocol” and ITM are somewhat synonymous and 
frequently used interchangeably. If one would like to discriminate, one might say that an ITM 
defines what can be computed in principle (i.e. defines the limits of the computational model), 
a code defines how something is computed (i.e. a list of instructions) and a protocol is both 
combined together (i.e. a code that is compatible with the capabilities of an ITM). If a protocol 
comprises different roles (e.g. the sender and receiver of a commitment protocol), the code z 
includes the code for all roles and the particular role of an ITI within the session is selected 
through appropriate input upon invocation. Please note, that a non-interactive program that is 
executed on a single ITI is also called a protocol. 

The UC framework defines security as a relative concept by comparison of a protocol to 
some other protocol and stating that the former is secure simply means that it is as least as 
secure as the latter. Hence, in order get any useful results, we need something that we assume 
to be inherently secure as our comparison object. These objects are called ideal functionalities 


and are defined next. 


Definition 3.6 (Ideal Functionality) An ideal functionality F is an ITM with the following 


special properties: 
(1) For each instance of F pid = L holds. 


(2) Dissenting from Definition 3.4 F is allowed to pass output to (and obtain input from) ITIs 
with pid’ + pid if they belong to the same session and run the code of the dummy party 


(see below). 


Definition 3.7 (Ideal Protocol, Dummy Party) A ideal protocol IDEAL¢ consists of an ideal 
functionality F together with an ITM, the so-called dummy party.’ An instance of an ideal protocol 


4 


Canetti sometimes uses the term party synonymic for a single ITM or ITI. Although the dummy party is a 
particular ITM (and not a set of ITIs sharing the the same PID) we keep this term. 
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Session 3 


a ITI — Input/Output --- Incoming/Outgoing Message 


Figure 3.2: A System of ITIs with an ideal functionality F 


consists of an instance of F and one instance of the dummy party for each PID that F passes 
output to. The instances of the dummy party have the same SID as the instance of F. If an ITI M 
invokes an ITI with the code of F with id = (pid, sid) for the first time, an instance of F with 
idg = (1, sid) and an instance of the dummy party with ida, y = (pid, sid) is invoked. The 
dummy party becomes a subsidiary of M. If another ITI M’ belonging to a different party passes 
input to an instance of F with id = (pid’, sid) and there is already an ITI with the code of F and 
SID sid, then only a suitable dummy party with id4ummy = (pid’, sid) is invoked. Dummy parties 
simple pass input/output between their parent ITI and the instance of F. 


Sloppily, ideal functionalities are thought to span across multiple parties and be part of each 
party via one dummy party (cp. Fig. 3.2). This allows ideal functionalities to conduct distributed 
tasks using (local) input/output only and evading the adversary for remote messaging. 

A reasonable security framework also requires a mechanism for the adversary to corrupt 
ITIs. 


Definition 3.8 (Corruption) The adversary A is allowed to corrupt ITIs with pid + L. In this 
case the content of all tapes of the corrupted ITI is handed over to A. From then on, A impersonates 
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the corrupted ITI. Whenever (local) input is passed to the corrupted ITI from its parent or from one 
of its subsidiaries via write-external, the message is written onto the input tape of A and A gets 
activated. Vice versa, the adversary A is allowed to pass input to the parent or the subsidiaries of 


the corrupted ITI as if the message came from the particular ITI. 


Descriptively, corruptions can be depicted as if the adversary incorporates the corrupted ITI 


and all communication lines from or to the ITI are re-attached to the adversary. 


Please note, that the condition pid # prevents ideal functionalities from being corrupted. 
However, dummy parties are corruptible and thus the adversary learns all past input/output of 
the ideal functionality for the particular party. Moreover, the ideal functionality is notified that 
the dummy party is corrupted. We stress, that the code of an ideal functionality may depend 


on the corruption status of its associated dummy parties. 


Deviations from the original UC framework Again, Definition 3.8 is more restrictive 
than the original corruption mechanism. In [Canoo; Cano5; Can13; Can18] the adversary 
corrupts an ITI through sending a special corrupt message to the ITI’s incoming message tape 
in order to express its wish to corrupt the recipient. The ITI can then decide to ignore the 
request, to surrender completely (as above) or to do something else; typically, this means to 
alter some parts of its tapes (e.g. erase secret keys) before handing over the tape’s content to the 
adversary. This enables different kinds of corruption models. The corruption model underlying 
Definition 3.8 in case of “normal” ITIs (not a dummy nor an ideal functionality) is called the 
Byzantine corruption model in [Canoo; Canos; Can13; Can18] and is the mostly used one. The 
fact that the adversary learns all past input/output upon corruption of a dummy party, is called 
standard corruption in [Cano5]. All ideal functionalities in [Canos] are of this type. We deem 
Byzantine corruption sufficient for two reasons. Firstly, considering real software it seems 
peculiar that an ITI should have the power to object to corruption. Normally, “programs” do 
not know if they are corrupted and allowing ITIs to run arbitrary code upon corruption might 
encourage the definition of protocols (in pseudo-code) that turn out to be unimplementable in 
the "real world" using real programming languages. Secondly, the UC framework provides 
an alternative approach to model incorruptible elements. Of course, there might be valid use 
cases where a more fine-grained reaction to corruption is desirable and is an essential part of 
the security concept. If certain parts of an ITI should withstand corruption and other parts 
not, then the system should be re-factored with the incorruptible parts being outsourced to an 
independent component that is modeled as an ideal functionality. We deem this alternative 


approach to be “the right one" as it spells out the required trust assumptions more explicitly. 


Finally, we are ready to define the UC experiment and UC security. 
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Definition 3.9 (Ihe UC Experiment) Let the environment Z and the adversary A be two 
ITMs as in Definition 3.4 and x a protocol as in Definition 3.5. Then EXEC, 4 7(1") is defined as 
the execution of the system (Z, A) on input 1” with the additional restriction that any ITI invoked 
by Z must have the same SID and the code of the ITI is (silently) enforced to be x. The output of 
EXEC, 4 z(1") is the output of (Z,A). The protocol x is called the challenge protocol. 


Definition 3.10 (Protocol Emulation, UC Realization, UC Security) Let x, y be two pro- 
tocols. We define 


I 2Uc 9 pes V AASV Z : EXEC, 4 7(1") Š EXEC, s 7(1") (3.1) 


In this case we say x emulates ọ or z is a (UC-)secure realization of p. The ITI S is called the 
simulator. Likewise, the left UC-experiment EXEC, 4 7(1") is called the real game and the right 
UC-experiment EXEC, s 7(1") the simulated game or ideal game. 


Sloppily, z UC-realizes o means that no environment Z is able to distinguish if it is interacting 
with an instance of the protocol z and a (real) adversary A or if it is interacting with an instance 
of the protocol g and a simulator S mimicking the behavior of A. The order of quantifiers is 
important, i.e. the simulator S may depend an A but must not depend on the environment Z. 
We highlight to definitional issues: As the environment Z believes to interact with instances 
of z Definition 3.9 enforces the challenge protocol to run the correct code agnostic to Z. Hence, 
the challenge session is an instance of pin the ideal game although Z believes to invoke z- 
instances. For the same reason, Item (2c-iii) in Definition 3.4 ensures that the sender's identity 
(which encodes the sender's code) is erased if instances of the challenge protocol pass output 
to Z. Otherwise Z could trivially distinguish the games. 

Definition 3.10 quantifies over two adversarial entities: the adversary A and the environment 
Z. The definition of UC-emulation can equivalently be rephrased such that only one specific 
adversary, the so-called dummy adversary D, needs to be considered. This greatly simplifies the 
application of Definition 3.10, as consequently only a specific simulator Sy for the prescribed 


adversary needs to be defined. 


Definition 3.11 (Dummy Adversary) The dummy adversary is an ITM with the following 


code: 


(1) If D is activated by a message m on its incoming message tape, or by an input m on its 
input tape that has not been passed by Z, D forwards the m’ = (idp, idz, m) as output to 
Z. 


(2) If D is activated by an input m’ = (idz, id p, m) with m = (corrupt, id) from Z, D corrupts 
the designated ITI and forwards the received internal state of the corrupted ITI back to Z. 
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(3) If D is activated by an input id = (idz, idp,m) from Z with m = (id 


D passes m as output or sends m as an outgoing message. Please note: D can only use the 


snd> id, y, m), then 


(local) output tape in the name of id,,q, if it has previously corrupted this ITI and thus D 


snd? 
incorporates this ITI. 


The next theorem states, that any protocol is already UC-secure, if it is secure with respect to 


the dummy adversary. 


Theorem 3.12 (Completeness of the Dummy Adversary) Let z and y be protocols and D 
the dummy adversary. Then x emulates py in the sense of Definition 3.10 if and only if m emulates 


ọ with respect to the dummy adversary. Formally: 


£ 


VAISVZ : EXEC, q 7(1") 
ie 3Sp9VZ : EXEC, y 70) = EXEC, s, z(1") 


EXEC, s 7(1") 
* (3.3) 


Informally, the dummy adversary is simply a thin communication wrapper around Z and helps 
Z to access the network. All “adversarial logic" has been put into the environment Z. For a 
proof, see [Canoo; Canos; Can13; Can18]. 

Before we conclude this section, we re-consider corruption. Both the scope of corruption 
and the time of corruption can be further restricted. The corruption mechanism as defined in 
Definition 3.8 allows ITIs belonging to the same party to be corrupted individually. Hofheinz 
and Shoup show that the UC Composition Theorem as stated in [Cano5] does not hold for this 
general type of corruption, but needs further restrictions. To keep matters simple, we only 
consider PID-wise corruption from now on. As the name suggests, this means the adversary is 


allowed to either corrupt no ITI of a party or must corrupt all ITIs at once. 


Definition 3.13 (PID-wise Corruption) A UC-experiment EXEC, 4 7(1") or a system of 
ITIs (Z,A) uses PID-wise corruption, if either all ITIs sharing the same PID are uncorrupted or 


corrupted. 


Additionally, the corruption model can be distinguished with respect to at what point of time 


the adversary is allowed to corrupt an ITI. 
Definition 3.14 (Static vs. Adaptive Corruption) 


(1) A UC-experiment EXEC, 4 7(1") or a system of ITIs (Z, A) uses static corruption, if the 


adversary is only allowed to corrupt ITIs before they receive their first input. 


(2) A UC-experiment or a system of ITIs uses adaptive corruption, if it is not static, i.e. the 


adversary is allowed to corrupt an ITI at any time. 
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A common misunderstanding is to deem adaptive corruption the more realistic model. The 
rationale behind this statement is that real programs or computers are usually not initially 
corrupted. However, this motivation falls short. First note, that UC-security quantifies over 
all adversarial strategies. This includes adversaries that statically corrupt a party but then 
follow the prescribed protocol honestly first and may deviate from the protocol later. From 
the perspective of another honest party this behavior is indistinguishable from a party that 
is honest first and then corrupted adaptively. Hence, for all scenarios in which security is 
only guaranteed to permanently honest parties and security for eventually corrupted parties is 
deemed irrelevant, static corruption is the adequate model. 

Instead, adaptive corruption is tightly related to deniability. Simplified, the simulator must 
simulate protocol messages without knowing the input/output of the honest party in the 
beginning and then upon corruption (when the simulator learns the party's input/output) 
contrive appropriate secrets that consistently explain the party's past messages. Typically, this 
means that the simulator has an algorithm that computes a consistent randomness given the 
actual past input/output, the transcript of messages and the keys. Then, this randomness is 
handed over to the environment by the simulator as the pretended randomness of the corrupted 
party. As the algorithm works for any tuple of input/output, transcript and keys, a modification 
of this algorithm can also be used by honest parties to plausible deny a particular input/output 
to any third party. 

For the sake of completeness, we shortly define the universal composition operator and state 


the composition theorem which lends the UC framework its name. 


Definition 3.15 (Universal Composition Operator) Let x, y and p be protocols. The proto- 


col 


SIN 


p (3.4) 
is identical to p with the following modifications: 


(1) Whenever p contains a write-external instruction with an extended identity id = (o, (pid, 


sid)) for the recipient, the instruction is replaced by an identical instruction with id = 


(x, (pid, sid)). 


(2) Whenever p? receives an input from an ITI with extended identity id = (xr, (pid, sid)), p? 
proceeds as p would do, if the input came from id = (9, (pid, sid)). 


Theorem 3.16 (Ihe UC-Theorem) Let x, y and p be protocols and let x >yc y hold. Then 
p? 2uc p holds. 


Fora proof see [Cani3]. The theorem stated there additionally demands z and gto be subroutine- 


respecting. This is implicit here, as Definition 3.4 only allows this kind of protocols. Instead of 
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p? Zuc p one usually writes p? >yc pP. The following corollary illustrates the most frequent 


application of Theorem 3.16. 


Corollary 3.17 (UC Composition) Let F and G be ideal functionalities and m, q be protocols. 
Then 
giFAly Suc IDEALg, z >yc IDEAL? — 97 >yc IDEALg (3.5) 


or more sloppily 
97 2uc G, n Duc F = 9" 2uc G (3.6) 


holds. 


3.4 Communication Model and Anonymity 


As described in the previous section there are two types of channels being hard-coded into the 


framework: 


(1) The first type is called input/output and provides reliable, immediate, confidential commu- 
nication between ITIs of the same party. This type is inspired by communication between 
individual processes that are executed within the same trust domain, i.e. typically a 


computer. 


(2) The second type is called incoming/outgoing messaging and provides communication 
between ITIs of the same session across different parties. This type does not provide any 


security properties and shall represent an unreliable network. 


Both types use the same kind of addressing mechanism: The actual message m is prefixed by 
the extended identity of the sender and the receiver. These extended identities contain the 
PID, the SID and the code of the respective party. We call this identity-based addressing. While 
this method seems adequate for inner-party (i.e. local) communication and suffices for our 
purposes, this method is problematic for cross-party (i.e. network) communication. Identity- 
based addressing does not appropriately capture how addressing is implemented real-world 
networks and thus does not only fall short to be a realistic model, but also prevents anonymous 
communication. 


There are three related issues: 
(1) The adversary/simulator always leans the sender’s true identity. 


(2) Even if the adversary/simulator erased the sender’s identity from the extended message 
(or replaced it by a fixed, fake identity), the recipient still would require the originator’s 


identity in order to send a reply. 
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(3) The communication model of the UC framework implicitly assumes, that the involved 
parties already have agreed beforehand upon what protocol they are going to run, who 


has what role using which PID and what SID they are going to use. 


Apart from the inability to adequately model real computer networks one might be tempted to 
argue that the issues (2) and (3) are only of minor concern. As the description of subordinated 
ITIs is included in their parent's code, the environment Z (implicitly) invokes all ITIs. As 
Z gives input to the parties and therefore controls their participation in a session, there is 
no anonymity with respect to Z. Hence, one might say that directly using identities instead 
of addresses is an acceptable simplification of the model that avoids an additional level of 
indirection. From this point of view the avoidance of additional network addresses is at most a 
blemish of the model and one might assume that all the technicalities of real networks such 
as session setup or address resolution are pulled back into Z. In particular, with respect to 
issue (2) a receiver could even reply to the correct originator of an anonymous message, if the 
environment wants so, because the environment knows the sender's identity and could pass 
the reply address as input to the receiver? Probably, issues (2) and (3) are part of the reason 
why common saying states that it is impossible to model privacy within the UC-framework. If 
the environment Z triggers two parties to interact with each other and then asks the dummy 
adversary D to report the observed messages, Z knows to whom the messages belong. We 
claim, however, that this is a misconception of anonymity. The question is whether in the ideal 
model the simulator S—without using any information about the parties’ identities—is able to 
simulate messages that are indistinguishable from messages that D reports to Z in the real 
model. If the ideal functionality only outputs non-identifying information to the simulator 
and the simulator is still able to generate a convincing transcript (from Z’s viewpoint), then 
anonymity is provided. But this is formally impossible due to issue (1). Remember that the 
dummy adversary in the real experiment receives an extended message ™ = (id, id, V, m). 
Even if the simulator was able to simulate the actual message m independent of the sender's 
identity, the simulator still needs to report a convincing extended message containing the 
sender's identity to Z. 

To solve these issues, we explicitly introduce an ideal functionality 75, for cross-party 
communication and completely give up on using the incoming/outgoing messaging that 
is hard-coded into the UC-framework. Our new messaging functionality Fnsg ensures the 


anonymity we require. Consequently, our real P5C protocol lives in a Fnsg-hybrid model. 


° Of course, the environment could lie about the originator's identity and input the wrong reply address to the 


recipient, such that the recipient sends its outgoing reply to the wrong destination. However, the network is 
under control of the adversary anyway and thus providing the recipient with the wrong originator's identity 
gives no additional power to Z. 
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As the real dummy adversary and the environment in the real game are aware of Finsg and 
thus do not expect to receive the sender’s identity, the simulator in the ideal model does 
not need to provide one neither. Using an ideal functionality allows us to stay in line with 
the original UC-framework and also makes our requirements on the communication very 
explicit. (Alternatively, we had to redefine the messaging mechanism which we feel to be the 


conceptually wrong way.) 


Fmsg is a multi-party functionality that supports polynomially many communication sub- 
sessions (within one UC session) between pairs of parties. A multi-party functionality that 
supports multiple sub-sessions allows a distinguished party? to announce its “existence” once 
in the beginning and from then on can be reached by other parties upon those parties' will. If 
we modeled 75, as a two-party functionality that only supported a single communication 
instead, a new instance of Fmsg Would have to be instantiated for each communication and 
this would again rise the question how the involved parties "find" each other in the first place. 
Several formulations for similar functionalities, e.g. Fun (authenticated communication), Fmt 
(secure message transfer), es (secure communication sessions), Fs. (relaxed secure channels), 
exist in the literature [Cano3; Cano5; CKoz; NMOos]. Auth provides bi-lateral authentication, 
but only supports a single (one-shot) message and no confidentiality. Zes captures the idea that 
communication is divided into three phases: first, a session is established utilizing some kind 
of communication identifier, second, several messages are exchanged in both direction and 
last the communication session is teared down again. However, %¿s does not provide any kind 
of security. Fmt provides confidential communication, but only support a single (one-shot) 


message again. 


Our functionality Fmsg can be depicted as a merge of these functionalities and is defined in 
Figs. 3.3 and 3.4. A party that becomes the initiator can establish a communication session that 
is identified by a sub-session identifier (SSID) ssid throughout its lifetime. A party that becomes 
the responder of the communication session can then accept the communication. Please note, 
that the term "responder" does not state anything about the direction of communication. The 
terms "initiator" and "responder" are only used to distinguish who started the session. Initiators 
can determine whether they want to stay anonymous or be identified by appropriately setting 
the mode mode € (anon, ident] when they establish a session. A session is always identifying 
for the responder. After a session has been established, polynomially many messages can be 
sent in both directions. If both parties are honest, the adversary only learns the length |m| 
and direction dir € (request, response} of each message. Again, please note, that the terms 


"request" and “response” shall not stipulate any communication structure, especially requests 


° This particular party is the operator in P5C, see later. 
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ty 


Functionality Fmsg 
L State 


A (partial) mapping fcomm-state assigning a triple of initiator PID pid 
PID pid 


E ; a : initiator? TSP onder 
responder and communication state to a sub-session identifier (SSID) ssid: 


feomm-state ^ SSID > PID x PID x (pending, active, closed} 


IL Behavior 


(1) Upon obtaining input (establish-session, mode, pid what) from a party 


responder’ 
with PID pid; itiatop, proceed as follows ... 
(a) Draw a fresh sub-session identifier (SSID) ssid that has not been used 
previously. 
(b) Set foomm-state(ssid) = (pid initiator’ Pid responder? pending). 
(c) If mode = anon, redefine pid; = + 
(d) Leak (establishing-session, ssid, pid; «i uo," pid ) to the adversary. 


(e) Output (establishing-session, ssid, pid 


responder 


initiator’ what) to party p roma 


(2) Upon obtaining input (accept, ssid) from a party with PID pid and there 


responder 
exists pid; tiator such that feomm-state(ssid) = (Pid initiator’ Pid responder? pending) 
holds, proceed as follows ... 
(a) Redefine feomm-state(Ssid) := (Pid initiator’ Pid responder’ active). 
(b) Leak/output (accepted, ssid) to the adversary and party pid; iiator- 
(3) Upon obtaining input (send, ssid, m) from a party with PID pid... 4, and there exists 
p id initiator’ p id. respondes such that 
f comm-state(ssid) = (p id; itiatop p id responder active) and 
pid na € {Pid initiator Pid } hold, proceed as follows ... 
(a) If pid 4 = Pidinitiator then set pid ey = pid 
set pid ey = Pid initiator and dir = response. 


(b) If pid... and pid ey are honest: 


responder 


responder and dir = request, else 


(i) Leak (sending, ssid, dir, |m|) to the adversary. 
Else (pid, ng or Pid cy is corrupted): 
(i) Leak (sending, ssid, dir, m) to the adversary. 
(ii) Obtain alternative value for m from the adversary. 


(c) Output (sent, ssid, m) to party pid ey 


Figure 3.3: The Functionality Finsg 
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Functionality Ins; (cont.) 


(4) Upon obtaining input (close, ssid) from a party with PID pid, and there exists 
P id nitiator P id responder such that 
fomm-state(ssid) = (Pid initiator’ P!4 responder’ active) and 


pid € {Pid initiator’ Pid responder) hold, proceed as follows ... 
(a) Redefine Scomm-state(ssid) = (Pid initiator’ Pid responder closed). 
(b) Leak/output (closed, ssid) to the adversary, and parties pid 


pid 


initiator’ 


responder’ 


Figure 3.4: The Functionality sg (cont. from Fig. 3.3) 


and responses do not need to come in pairs. They are only used to leak the direction of the 
message to the adversary without breaking the initiator’s anonymity. If one of the parties 
is corrupted, the adversary learns the whole message m and may alter it. Finally, any of the 
involved parties may close the communication session. 

Fmsg provides the following high-level security properties (if both communication partners 
are honest): Messaging is either bilateral authenticated or one-sided authenticated and one- 
sided anonymous. Even if the initiator is anonymous, integrity of messages is always ensured. 
Also, Fmsg ensures that within a single session the initiator is always the same party despite 
being anonymous. Lastly, messaging with Fnsg is confidential. 

We conclude this section with some final remarks on the realizability of Fnsg by a real 
protocol. Of course, 75, is trivially unrealizable in the first place due to its anonymity 
feature (see above). However, this is more of a definitional problem of the UC model. Assume 
for a moment that we only consider authenticated communication and only use Fmsg with 
mode = ident. Canetti [Canos, Claim 20] shows that 7; is unrealizable in the plain model. 
Obviously, Zu) can be realized by 75,4 plus a wrapper protocol that restricts Fmsg to a single 
sub-session and a single message. In conclusion, Ins; is also unrealizable in the plain model 


even in disregard of anonymity. 


3.5 Setup Assumptions and Writing Conventions 


Security under universal composition is a very strong notion and thus faces impossibility 
results in the plain model. Especially, Canetti and Fischlin [CFo1] show that UC-secure com- 
mitments are impossible without setup assumptions. Setup assumptions are modeled as ideal 
functionalities that are facilitated by the real protocol in order to bootstrap security. In other 


words, in the real security experiment the protocol is still a hybrid with some components being 
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Functionality Fors 


Public parameters: Security parameter n, PPT-algorithm Setup 


L Receive CRS 


Party P input: (retrieve) 
(1) If no crs has been internally recorded, run crs + Setup(1”) and store crs internally. 
(2) Load the internally recorded crs. 


Party f? output: (crs) 


Figure 3.5: The CRS Functionality Fers 


left idealized. These setup assumptions enable a security proof, because the ideal functionality 
implementing the setup assumption is a subordinate of the real protocol and thus is not directly 
accessible by the environment. This provides the simulator in the ideal experiment with a lever 
to lie about the setup assumption, e.g. to embed a trapdoor, and thereby avoids the impossibility 


results. 


3-5-1 The Common-Reference String Model 


A typical and widely used setup assumption is the CRS (common-reference string) model. A 
CRS is a short piece of information, i.e. a bit-sequence, that is shared among all parties and has 
been trustworthily generated. The ideal CRS-functionality Fers is depicted in Fig. 3.5. 

We like to elaborate on the usefulness of the CRS-model. Depending on the way how the CRS 
is utilized, the model is more or less realistic. For example, following a modular approach where 
first a real protocol is defined using commitments as idealized UC-functionalities Fom and 
then these commitments are replaced by real commitment protocols in the CRS-model using 
the composition theorem, a fresh instance of F¿ps is required for each commitment. This stems 
from the requirement of the composition theorem that protocols must be subroutine-respecting 
and that Feps is local to each commitment. Hence, this approach is highly wasteful on the 
CRS and it is questionable where a sufficiently long CRS should come from. We stress that it 
is impossible to generate the CRS with plain cryptographic means by the parties themselves 
without violating the impossibility result and thus sacrificing security. As the CRS must 
come from outside the model the CRS should be succinct and efficiently used by the protocol. 
This applies to our scheme. A single instance of P5C supports polynomial many parties in 


polynomial many interactions using the same small CRS. In other words, in our particular case 
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Functionality Fpp 
I Register 


Party P input: (register, (key,, key,, ...)) 
(1) Send (registering, pidp, (key, key,, ...)) to the adversary. 
(2) Upon receiving OK from the adversary proceed, else abort. 
(3) If another entry (pidg, (...)) has already been registered for pidg, abort. 
(4) If 4 pidy, and i, j such that (pid,,,, (..., key;,...)) has been recorded and key; = key, 
holds, abort. 
(5) Internally record the pair (pidp, (key, key,, ...)). 
Party P output: (OK) 


I. Retrieve 
Party P input: (retrieve, pid) 

(1) Look up (pid, (key,, key,,...)) internally; set (key,, key,,...) = L if no record exists 
Party P output: (pid, (key,, key», ...)) 


II. Reverse Retrieve (Partial, reverse lookup) 


Party P input: (reverse retrieve, j, key) 
(1) Look up (pid, (key,, key),..., key; ...)) with key; = key internally; set 
(key,, key,, ...) = Lif no record exists 
Party P output: (pid, (key,, key, ... )) 


Figure 3.6: The Bulletin Board Functionality Fpp 


it is plausible to assume that the CRS is generated by some trustworthy state authority or by 


some standardization committee beforehand. 


3.5.2 The Bulletin Board or Key Registration Service 


Moreover, our scheme makes use of a bulletin board Fpp [CSV16, Fig. 3], which is sometimes 


also referred to as a key registration service [Cano7; Bar+04]. A bulletin board can be depicted 


as a database which associates party identifiers (PIDs) with (cryptographic) public keys. The 


assumptions about Fpp are that upon registration the operator of the bulletin board checks 


the identity of the registering party in a trustworthy way and that every party can retrieve 


information from Fpp trustworthily. Fpp is depicted in Fig. 3.6. We slightly enhanced Fpp 


over the usual definitions. This modification is not significant and does not have any impact 
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on how Fpp can be realized in principle. The modification is only required for syntactical 
purposes. F; does not only allow a single opaque bit-string to be registered as the only key 
per party, but a vector of bit strings. This is necessary as the reverse lookup allows to search 
for a particular component and not only for a complete string. Intuitively, this captures the 
fact that in complex systems the key is actually a composed key for several building blocks, i.e. 
one key for a particular instantiation of an encryption scheme, another key for a particular 
signature scheme, and so on. The reverse lookup allows to identify a party, given only one 
component of the key. To this end pairwise inequality of keys must not only hold for complete 
keys, but for every component of a key. Having realistic building blocks in mind this is not a 


severe restriction. 


Fpp is unrealizable in the plain model without authenticated channels, i.e. without another 
setup-assumption [Cano3, Sec. 3.2]. However, the other way around Fpp can also be used to 
realize authenticated channels Fuath or our messaging functionality Fmsg. In this case, a real- 
world implementation of Fpp needs to trusted that it correctly verifies the PID of a party outside 
the model. In our scenario the PIDs of users could be a passport number, SSN, a customer ID 
or any other reasonable, verifiable and unique attribute. For PoSes the geo-location could be 
used as a PID. 


Again, we like to shortly sketch how Fpp could be implemented in our scenario. Looking 
ahead, P5C puts us in the lucky situation that the scheme only exhibits a restricted commu- 
nication pattern. Users only communicate with PoSes and the operator but never with each 
other. Vice versa, the inverse holds for the PoSes, with the additional benefit that users remain 
anonymous. Moreover, there is only a unique operator of the system that stays the same all 
the time and the set of PoSes is rather static. Only the set of users is relatively dynamic. Hence, 
Fpp could be implemented as a simple list that is locally (and partially) stored at each party and 
infrequently updated. This frees us from the problem that the bulletin board needs to remotely 
accessible over an online connection, which itself would require some sort of authentication 
again. Each PoS only needs to know the key of the operator. This could be set upon deployment 
of the PoS and updated during maintenance, if necessary. Users need the key of the operator 
and a list of keys of valid PoSes. Again, this list could be installed/updated at the user's side 
when the user wallet is issued. Inversely, the operator needs a list of keys of all users and 
PoSes. But this is not a problem at all, because the operator owns/maintains the PoSes and 
users must register with the operator which we assume to happen in person. At the bottom 
line, the security assumption boils down to the ability of the parties to mutually verify their 
(physical) identities and to exchange their public keys over a local connection (e.g. an NFC 
reader) when meeting face-to-face without a man-in-the-middle. In summary, we deem this a 


very mild trust assumption. 
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3.5.3 Some Writing Conventions 


Lastly, we assume our functionality also uses the implicit writing conventions for ideal func- 
tionalities [Canoı]. In the real experiment parties need to communicate over the network. 
Hence, a party that expects to receive a message does usually not proceed nor output anything 
until the adversary delivers the message. Contrary, ideal functionalities use local input/output 
and thus normally react immediately per definition. In order to enable indistinguishability, the 
ideal functionality must provide the simulator with a lever to delay output. Formally, an ideal 
functionality asks the simulator for permission to pass output to a party. To this end the ideal 
functionality sends its a suitable request to the simulator. This request does not contain the 
actual output (which remains secret) but is equipped with a unique “output ID” that uniquely 
identifies this output. When the simulator replies with the same output ID, the associated 
output is eventually passed to the party. The output IDs also allow to re-order outputs to 
some extent. For example, if a sender broadcasts a message to several recipients in the real 
experiment and the ideal functionality passes output to the same set of recipients, the simulator 
must be able to re-order the sequence of outputs in correspondence to the order of delivered 
messages in the real experiment. 

As this entails a lot of boilerplate code that does not provide any insight, we simply assume 
this mechanism to be implicit to all ideal functionalities and that they “just do the right thing”. In 
particular, our simulator can delay outputs and abort the current tasks of the ideal functionality 


at any point. 
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In this chapter we formally define our ideal functionality fpc- Usually, ideal functionalities 
are rather simple objects and immediately evince that they capture the “right” definition of 
security. At least this is true for ideal functionalities that define cryptographic primitives like 
commitments, encryption or oblivious transfer. But here, fpc defines security and privacy for 
a complex, real-world system and is almost a protocol on its own. Therefore, we also try to 


"! choices are the best 


motivate why the definition is the way it is and why seemingly “insecure 
we can hope for. An explicit mapping of the properties identified in Section 2.6 onto the ideal 
model is given in Chapter 5. A summary of the used variables is listed in the appendix as a 
quick reference. 

We do not formalize each task (e.g., IssueWallet, Deposit, ...) as an individual ideal functional- 
ity, but the whole system as a monolithic, highly reactive functionality fpc with polynomially 
many parties as users and PoSes. A monolithic functionality allows for a shared state between 
the individual interactions and to define correctness, security and privacy more easily. We will 
therefore first explain this state in Section 4.1 before we go on to describe the behavior of ape. 
The ideal function fpc provides twelve different tasks in total which we divide up into three 
categories: “Setup Tasks” (comprising all party registration and CertifyPOS) are defined in Sec- 
tion 4.2. “Main Tasks” (IssueWallet, Deposit and Disburse) are defined in Section 4.3. Finally, 
“Utility Tasks” (ProveParticipation, DetectDS, VerifyGuilt and BlacklistWallet) are covered in 
Section 4.4. 


4.1 The Internal State 


The key idea of Zap. is to internally keep track of all conducted transactions in a pervasive 
transaction database TRDB (see Fig. 4.1). Note that in this case “transaction” refers to the tasks 
IssueWallet, Deposit or Disburse, not just Deposit. Each transaction entry trdb € TRDB is of 


the form 


trdb = (sP!*V, s, p, x, A, pid, pid, p. b Ods: Ores Opp). (4.1) 


1 N.b.: The ideal functionality cannot be insecure per definitionem. However, it could capture a concept of security 


that does not coincide with the intuitive perception of security. 
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Functionality fpc 
State 
* Set TRDB = {trdb} of transactions 
trdb = (sP'*", s, o, x, A, pid q pidg, p, b, Ogg, Orc, Opp) 


€ Sx 5x x No x Lx PIDYy x PIDp x Zy x Zy 
x {0, 1}* x {0, 1}* x {0, 1". 


e A (partial, injective) mapping fg assigning a fraud-detection ID y to a pair of wallet 
ID A and counter x: 
fo : Lx No > 8, (A, x) > Q 


* A (partial) mapping fa, assigning user attributes to a wallet ID A: 
Say ` £> AA ay 
* A (partial) mapping fa, assigning PoS attributes to a PoS PID pid: 


Sap : PIDp > Ap, pidp > ap 


A (partial) mapping f; assigning a validity bit to a pair of user PID pid,, and proof 
of guilt x: 
Fr : PEDqy x II > 10K, NOK} 


A injective mapping fo, assigning a blacklisting tag cj to a wallet ID A: 


fo, : £> Oy A oy 


Behavior 

e Dispute Resolver Registration (Fig. 4.4) e Disbursement (Fig. 4.12) 

* Operator Registration (Fig. 4.5) e Double-Spending Detection (Fig. 4.13) 
* Point-of-Sale Registration (Fig. 4.6) - Guilt Verification (Fig. 4.14) 

* User Registration (Fig. 4.7) e Wallet Blacklisting (Fig. 4.15) 


Point-of-Sale Certification (Fig. 4.8) e Balance Recalculation (Fig. 4.16) 


7 Wena (Fb) e Prove of Participation (Fig. 4.17) 


e Deposition (Figs. 4.10 and 4.11) 
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Figure 4.1: The Functionality Jpc - Internal State and Overview of Tasks 


4.1 The Internal State 


: : 5, Q, X, A, pid, b 
‚prev Did, P, Ods» Orcs pp P pies, 


C o 


Figure 4.2: An entry trdb € TRDB visualized as an element of a directed graph 


It contains the identities pid;, and pid, of the involved user and PoS (or operator in the case 
of IssueWallet and Disburse), the wallet ID A of the wallet that was used as well as the price 
p associated with this particular transaction and the total balance b of the user's wallet after 
this transaction, i.e., the accumulated sum of all prices so far including the current transaction. 
In other words, fpc implements a trustworthy global bookkeeping service that manages the 
wallets of all users. Each transaction entry is uniquely identified by a serial number s and links 
via sP'*" to the previous transaction trdbP™®Y which corresponds to the wallet state prior to trdb. 
Additionally, each entry contains a counter x indicating the number of subsequent transactions 
of a wallet since its generation, i.e. x = xP"Y + 1 always holds, and a fraud-detection ID y which 
is required for double-spending detection. 

The database TRDB can best be visualized as a directed graph with each trdb entry repre- 
senting a node together with an edge pointing to its predecessor (see Fig. 4.2 for a depiction). 
Each node represents the state of a wallet after the respective transaction, i.e., at the end of an 
execution of IssueWallet, Deposit or Disburse, and the edges correspond to the transition from 
the previous to the next state. Nodes are identified by serial numbers s and additionally labeled 
with (9, x, A, pid, , b). The edge to the predecessor is identified by (sP**%, s) and additionally 
labeled with (pid,,, p, Ods: Orc» Opp). 

Also, each transaction, or more precisely each transition from one wallet state to the next, is 
associated with various tags: the double-spending tag wg,, the recalculation tag c. and the 
prove-participation tag «y. A forth tag, the blacklisting tag c, is not depicted here. The latter 
is only generated, when a wallet is issued and thus belongs to the “imaginary transition” from 
the void to the root node. Therefore, cj is not recorded in trdb but separately kept by fpc in 
the map fo, (cp. Fig. 4.1). In short, these tags serve as a kind of receipt or "evidence" for certain 
aspects of a transaction and store implementation-specific information. Their description is 
postponed to Section 4.1.2. But first some explanations are in order with respect to the different 
IDs that are attached to each transaction, namely the serial number s, the wallet ID A and the 


fraud-detection ID 9. 


4.1.1 Transaction Identifiers 


In a truly ideal world, fpc would use the user's identity pid¿, and a wallet ID A to look up its 
most recent entry in the database and append a new entry. Such a scheme, however, could only 


be implemented by an online system. Since we require offline capabilities—allowing a user and 
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PoS to interact without the help of other parties and without permanent access to a central 


authority—the inherent restrictions of such a setting must be reflected in the ideal model: 


« (Even formally honest) users can misbehave and commit double-spending without being 


noticed instantly. We call these users honest, but misbehaving. 
* Double-spending is eventually detected after-the-fact. 


In order to accurately define security, these technicalities have to be incorporated into fipo 
which causes the bookkeeping to be more involved. 

To ease the upcoming definition of fpc we bring forward some properties of the transaction 
database TRDB. In Section 5.1 we show that TRDB is a directed forest with labels as described 
above and prove some invariants. But there we reverse the train of thought, take the definition 
of 755. as a starting point and then prove that fpc actually yields a graph with the desired 
properties. Here, we start from our goal and describe our intention behind the transaction 
database to enable an intuitive understanding. 

A user's wallet is represented by the subgraph of all nodes with the same wallet ID A and 
forms a tree inside the forest (see Fig. 4.3). If a new wallet is issued, IssueWallet creates a new 


entry of the form 


(L, s, 9, 0, À, pidqp pido 0,0, toas, Orcs Opp). (4.2) 


These transactions have no predecessor and are root nodes of new wallets. Therefore, sP'*" = 1 
and also p = 0 holds. Deposit and Disburse extend a tree. The task Disburse clears a wallet's 


balance and the corresponding entries are leaf nodes of their tree with the restricted form 
(SP s,Q, x, A, pid,, pido, —pbill o, Ods Ores Opp) (4.3) 


Every other task than IssueWallet, Deposit and Disburse does not alter TRDB but only queries 
it. 

Unless a user commits double-spending with a wallet the particular subgraph is a linked, 
linear list. If a user misbehaves and reuses an old wallet state (i.e., there are edges (sP'*", s) 
and (sP"°V, s’)), the corresponding subgraph becomes a directed tree. The counter x equals 
the depth of a node in a tree and the fraud-detection ID y is an injective, random function 
fo : Lx No > 8,(A,x) > y of the pair (A, x) of wallet ID and counter. If and only if a node is 
not part of a double-spending, the pair (A, x) is globally unique and therefore g. Otherwise, all 
transaction entries that constitute a double-spending, i.e., all nodes with the same predecessor, 
share the same counter value x and the same fraud-detection ID q. 

Although the database TRDB and the mapping fg contains most of the required information, 
Tape Stores four more partially defined mappings. fay : L > Aq and fa, : PIDp > Ap 
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pid4, = Alice pid4, = Alice pid, = Alice 
A=1,x=3 |e A=1,x=4 |e A=1,x=5 
s=25,9=11| : |s=3,p=19 s=9,9=31 


j 

l 

l 

| pid,, = Alice 
l A=1,x=2 
s=17,9=14 pid, = Alice 
A=1,x=3 
i : s=8,p=11 
| 

l 

| 

l 

l 

| 

l 


g=11 
pid,, = Alice pid,, = Alice pid,, = Alice 
A=3,x=1 A= 3: mo = 2 A=3,x=3 
s = 18, p = 42 s=32,p=6 s=12,p=2 


Wallets that belong to the same user a grouped by a dashed line. The serial number sis globally unique 
for a node. Nodes that belong to the same tree (aka wallet) share the same wallet ID A (here: 1, 3 or 6). 
The counter x equals the depth of a node. The fraud-detection ID gis an injective, random function of the 
pair (A, x). Unless double-spending occurred, (A, x) is also globally unique and thus @, too. Nodes that 
belong to the same double-spending sharing the same fraud-detection ID y are grouped by a dotted line. 


Figure 4.3: The transaction database TRDB visualized as a directed forest 
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keeps tracks of parties’ attributes by internally storing PoS attributes ap upon certification 
and user attributes aq, when a wallet is issued. The mapping f; keeps track of proofs of guilt 
that are issued or queried in the context of double-spending detection. The already mentioned 


mapping fo. keeps track of blacklisting tags that are generated when a new wallet is issued. 


4.1.2 Tags and the Synchronization of State 


As already briefly touched in the introduction of this section each transaction is associated to a 
collection of so-called "tags" that are stored in the transaction database alongside the actual 
information about the transaction. Their common characteristic is that they serve as a sort of 


digital receipt and each type of tag goes with one of the utility tasks: 


* Double-spending tags wg, are generated when points are deposited to or disbursed from 
a wallet and later used by DetectDS to enable the operator to check if users have used 


the same wallet state repeatedly. 


e Prove-participation tags cy; are generated when points are deposited to a wallet and 
alter used by ProveParticipation and allow users to prove that they have participated 
in a particular transaction when they are summoned by the violation enforcer despite 


being primarily anonymous. 


e Recalculation tags wrc; are generated when points are deposited to or disbursed from 
a wallet and later used by RecalculateBalance to enable the operator to recalculate the 


balance of a wallet. 


« Blacklisting tags «yj; are generated when a new wallet is issued and later used by 


Blacklist Wallet to exclude a particular wallet from further participation in the system. 


The same that is being said about the different identifiers in Section 4.1.1 also applies to the 
tags. In a truly ideal world, none of these tags would be required and 9,,. could be defined 
without them. For example, in order to prove participation in a particular transaction the user 
and violation enforcer could simply input the whereabouts of the transaction into 74, and 
Tape merely uses its global transaction database to undoubtedly acknowledge (or deny) if such 
a transaction has been recorded. Similarly, in order to recalculate the balance of a particular 
wallet, the operator could input the wallet ID A into Jape and fpc easily sums over the prices 
p for all recorded transactions with that wallet ID. Unfortunately, this would be an overly 
idealized model and could not be realized, at least not by a system in that information is stored 
in a decentralized way with offline capabilities. In such a system inconsistencies naturally 
arise. For example, when a user and a PoS have completed a transaction but the PoS has not 


yet sent the accounting information to the operator, the operator incapable of considering this 
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transaction when a balance needs to be recalculated. These technicalities must be accurately 
modeled by the ideal functionality to let the security proof go through. An alternative approach 
instead of using tags is discussed in Section 5.4.1. That section also points out some of the 
errors in [Nag+20]. 

We stress, that the ideal model does not stipulate how theses tags look like nor what they 
encode. These details are left to the eventual realization. From the perspective of fap. these tags 
are treated as opaque bit strings that are "placeholders" to be filled out by the simulator in the 
security proof. The ideal functionality uses the tags only in so far to "flag" which transaction is 
known by which party. For fpc the global transaction database TRDB is the only authoritative 
source of information. 

Typically, the tags are only passed through as output to a party and later re-input. This 
raises the problem that the environment can also input tags which have never been output by 
any task of the ideal functionality before but are made-up by the environment. We coin the 


following terms. 


Definition 4.1 (Genuine vs. Fake Tags) Ifa tag is input to a task of Faye by any party and 


the tag has been output before, we call it a genuine tag. A tag that is not genuine is called a fake 


tag. 


Skipping ahead to the definition of all tasks of 7,,. a tag is genuine, if and only if it is recorded 
in TRDB (in case of wgs; Opp» Myc) or if fa ow) is defined (in case of œp). In other words, all 
tasks of fpc are defined such that they never output a tag without recording it in the internal 


state. 


4.2 Setup Tasks 


To set up the system two things are required: All parties—the dispute resolver, operator, PoS 
and users—have to register to be able to participate in the toll collection system. As all of these 
registration tasks are similar, we will not describe them separately. In addition, PoSes needs to 


be certified by the operator. 


4.24 Registrations 


The tasks of RegisterDR, RegisterOp, RegisterPOS and RegisterUser (cp. Figs. 4.4 to 4.7) are 
straightforward and analogous. Upon invocation by the respective party through the input 
register, these tasks notify the adversary about the registration. This model that the informa- 
tion whether a particular party participates in the system is public. In case of the operator, the 


respective task additionally receives an attribute vector ao which defines the PoS-attributes 
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Functionality Apc (cont.) - Task RegisterDR 


Dispute resolver input: (register) 
(1) Leak (registering dr, pid pp) to the adversary. 


Dispute resolver output: (registered) 


Figure 4.4: The Functionality Fapc (cont. from Fig. 4.1) - Task RegisterDR 


Functionality 7). (cont.) - Task RegisterOp 
Operator input: (register, ay) 
(1) Leak (registering op, pid y, ay) to the adversary. 
(2) If fa, (pido) is undefined, set fa, (pido) = ag. 
Operator output: (registered) 


Figure 4.5: The Functionality 9%). (cont. from Fig. 4.1) - Task RegisterOp 


Functionality Apc (cont.) - Task RegisterPOS 


PoS input: (register) 
(1) Leak (registering pos, pid,,) to the adversary. 
PoS output: (registered) 


Figure 4.6: The Functionality fpc (cont. from Fig. 4.1) - Task RegisterPOS 


Functionality fpc (cont.) - Task RegisterUser 
User input: (register) 
(1) Leak (registering user, pid, /) to the adversary. 
User output: (registered) 


Figure 4.7: The Functionality fpe (cont. from Fig. 4.1) - Task RegisterUser 
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Functionality Apc (cont.) - Task CertifyPOS 


PoS input: (certify pos) 
(1) If RegisterOp or RegisterPOS have not yet been run, output 1 and abort. 
Operator output: (certifying pos, pid,,) 
Operator input: (certifying_pos, ap) 
(2) Leak (certifying pos, pidg, ap) to the adversary. 
(3) Set fa, (pid) = ap. 
PoS output: (certified pos,ap) 
Operator output: (certified pos) 


Figure 4.8: The Functionality fpc (cont. from Fig. 4.1) - Task CertifyPOS 


that are used by the operator when acting like a PoS, for example in the tasks IssueWallet and 


Disburse. For a discussion of the attributes see Section 2.4. 


4.2.2 Point-of-Sale Certification 


CertifyPOS (cp. Fig. 4.8) is a two-party task between the operator and an PoS in which the 
PoS is assigned an attribute vector ap. Again, we refer to Section 2.4 for a discussion on 
these attributes. The attribute vector ap is chosen by the operator after it has learned the 
PoS’ identity, while the PoS only inputs its desire to be certified. Zap, (re-)defines the partial 
mapping f, (pid) := ap which internally stores all PoS attributes. The identity pid, and 
attributes ap are leaked to the adversary before the attributes are output to the PoS. 

Please note, that the proposed definition of CertifyPOS is extremely simple and enables 
effects that are probably undesirable in a real-world application. In order to model re-certi- 
fication of a PoS fpc allows to overwrite fa, and thereby annihilate a previous version of 
the attributes. Skipping ahead, let's assume that the number of points a user gains in Deposit 
depends on fap. Further assume that the balance of a user's wallet is recalculated by the 
operator at some later point of time and that the PoS' attributes have been changed in the 
meantime. In this case the re-calculated balance and the balance that is stored in the wallet 
won't match. This is even true, if all parties have been honest. 

To remedy this problem in the ideal model, we would need to introduce a sequence of 
"versions" of fa; for a version counter ¿and log the temporal order of all transactions, i.e. 
equip each transaction with ¿to indicate which version has been in effect at the time of the 
transaction. This would complicate the ideal functionality even more. Also note, that a secure 


realization would be quite involved, too. It would not suffice, if the operator locally stored a 
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history of all past certifications, because a malicious operator had the power to lie about it. If 
a consistent re-calculation of the balance under intermittently changing attributes was one 
of the security properties, a secure realization would at least require that the attributes are 
irreversible logged in a publicly verifiable way, before they become effective. To keep matters 


simple, we ignore this problem. 


4.3 Main Tasks 


Now we describe the main tasks one would expect from any anonymous point collection 
system: IssueWallet, Deposit and Disburse. As mentioned before, these are the only tasks in 


which transaction entries are created. 


4.3.1. Wallet Issuing 


IssueWallet (cp. Fig. 4.9) is a two-party task between a user and the operator in which a new 
wallet is created for the user. After the operator has learned the user’s identity, the operator 
inputs an attribute vector aqy. The operator is free to abort at this point, if users shall not 
obtain a new wallet, e.g. because they have been identified as fraudsters in a previous run 
of DetectDS. First, fpc randomly picks a (previously unused) serial number s for the new 
transaction entry trdb. A new wallet ID A and fraud-detection ID y are uniquely and randomly 
picked, unless the user is corrupted in which case the adversary chooses q. This may infringe 
upon the unlinkability of the user’s transactions and we do not give any privacy guarantees 


for corrupted users. Finally, a transaction entry 
trdb = (L, s, 9, 0, A, pid, pido, 0,0, L, L, L) (4-4) 


corresponding to the new wallet is stored in TRDB and the wallet's attributes fa, (A) := aq; 
are appended to the partial mapping fa, Fape asks the adversary to provide a blacklisting tag 
@pı Which internally recorded as being associated to the wallet through the partial mapping 
fa, The blacklisting tag is re-used in the utility task BlacklistWallet. Both parties get the 
serial number s as output. The user also receives the attribute vector aq, to check out-of-band 
that it has been assigned correctly and more importantly does not contain any identifying 


information. The operator receives the blacklisting tag a). 


We stress that 9). does not really use the blacklisting tag «yj, but only passes it through. 


For a discussion of the tags see Section 4.1.2. 
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Functionality Apc (cont.) - Task IssueWallet 


User input: (issue wallet) 


(1) If RegisterOp, RegisterUser or RegisterDR have not yet been run, output Land 
abort. 


Operator output: (issuing wallet, pid,,) 
Operator input: (issuing wallet, aq,) 


(2) Pick serial number s È Sand wallet ID A È £ that has not previously been used. 
(3) If pid, , € PLD corr or pido, € PID corr, leak (issuing wallet, s, aq) to the adversary." 


(4) Pick fraud-detection ID y È 5 that has not previously been used, or—if 
pida, € PLD cox, —leak (issuing_wallet) to the adversary and ask for fraud- 
detection ID p that has not previously been used.” 


(5) Append fo(A, 0) = pto fo. 


(6) Leak (issuing_wallet) to the adversary and ask for a blacklisting tag cj that has 


not previously been used. 
(7) Append trdb := (L, s, 9,0, A, pid, ,, pido, 0,0, L, L, L) to TRDB 
(8) Set fa, (A) := au. 
(0) Set fa (A) = oy, 
User output: (issued wallet, s, aq) 
Operator output: (issued wallet, s, yj) 


a 


N.b., this leakage does not weaken the "actual" security at all. The serial number s is output to both parties 
(see below), and the attribute vector aq, is input by the operator and output to the user. Hence, if any of 
these parties is corrupted, the adversary learns this information anyway. This early leakage ahead of time is 
only a concession to the final implementation to enable the simulation of messages in the correct order. 
Picking the upcoming fraud-detection IDs randomly asserts untrackability for honest users. For corrupted 
users, we do not (and cannot) provide such a guarantee and the fraud-detection ID might be chosen 
adversarially (cp. text body). 


Figure 4.9: The Functionality fpc (cont. from Fig. 4.1) - Task IssueWallet 
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4.3.2 Deposition 


This two-party task (cp. Figs. 4.10 and 4.11) is conducted whenever a user interacts with a PoS 
and serves the main purpose of depositing points on a user’s wallet. 

This task is by far the most complicated and it is not straightforward to see why it captures 
a sane definition of security. For the ease of presentation, we first describe the behavior of Faye 
in the completely honest case without misbehaving, i.e. all parties (user, PoS and operator) are 
honest, and the user is neither blacklisted nor commits double-spending. After that we describe 
the restrictions and conditional branches of code which are required to obtain a definition that 
is actually realizable under corruption in our setting. Please note, although the operator seems 
not to be immediately involved in the task Deposit as a participating party, the definition still 
depends on the corruption status of the operator. Remember that within a single instantiation 
of fpc polynomial many parties can interact within polynomial many tasks and thus the 
operator is implicitly involved. This has been one of the oversights in [Nag+20]. 

To start a deposition of points, users input a serial number sP!*", indicating which past wallet 
state they wish to use and the identity of the PoS they want to interact with. Of course, well- 
behaving users always use the most recent state of a wallet. The participating PoS in turn 
inputs a blacklist blg of fraud-detection IDs. 


pPrev 


Firstly, fpc looks up if a wallet state trd in TRDB corresponds to the provided serial 


number sP!ev 


and belongs to the correct user with PID pid, ,. This guarantees that users can only 
deposit points on a wallet which has been legitimately issued to them. The ideal functionality 


uses part of the information from the previous wallet state 
trdbP = (s gPrev prev, „Prev APIS. pidqp pid", .pPrev . a, ) (4.5) 


to determine those parts of the new transaction entry trdb which remain constant for transac- 
tions within the same wallet. fpc randomly picks a fresh serial number s for the upcoming 
transaction, the user PID pid,, and wallet ID A stay the same, pid; is set to the identity of the 
participating PoS and the transaction counter (x := xP" + 1) is increased by one. In the com- 
pletely honest case without misbehaving, the map fg(A, x) is always undefined (cp. Step 6 in 
Fig. 4.10). Fape ties a fresh, uniformly and independently drawn fraud-detection ID ((A, x) + q) 
to the x'th transaction of the wallet A. This fraud-detection ID q is checked against the blacklist 
bla. Note, that the probability to blacklist a freshly drawn fraud-detection ID is negligible. 
Moreover, Jape looks up the user's attributes bound to this particular wallet (aq, :— fa, (A)) and 
the attributes of the current and previous PoS (ap := fa, (pid), üb SY = fap pid). The 
current serial number s, the current fraud-detection ID y together with the attributes of the 
user and the previous PoS are output to the PoS which chooses the price p of this transaction. 


We refer the reader to Section 2.4 for a justification why the PoS chooses the price unilaterally. 
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Functionality %,p. (cont.) - Task Deposit, Part 1 
User input: (deposit, sP'**, pid.) 
(1) If RegisterOp or RegisterPOS have not yet been run, output 1 and abort. 
(2) Select (+, sP*eY, Prev. xPFev, APS, pid, po pu^, -, DPYEY, ....) € TRDB with 
(sP'*", pid, ) being the unige key. 
PoS output: (depositing) 
PoS input: (depositing, blo) 


(3) Pick serial number s È S that has not previously been used. 
(4) If pid, € PEDeorr or pid, € PID corr, leak (depositing, s, a/) to the adversary." 
(5) Set A := API*" and x := xPI** +1. 
(6) If fa (A, x) is already defined: 
(a) Set o = f(A, x). 
(b) Leak (depositing, pid, ,, a) with 


proof of guilt x € IT for that f,Lpid., 77) = NOK has not yet been defined. 
(c) Set f,(pidq, T) = OK. 
Else: 
(a) Pick fraud-detection ID Q È 5 that has not previously been used, or—if 


pid4, € PID corr —leak (depositing) to the adversary and ask for fraud- 
detection ID y that has not previously been used.“ 


(b) Append f(A, x) := pto fo. 
(7) If ọ € bla, output blacklisted wallet to both parties and abort. 
(8) Set ay = fa, 2), ap = fa, (pid), and ab^" = fa, (pide ).- 


prev 


PoS output: (depositing, s, aqy, Ap ) 


l If this does not exist, abort. 


N.b., this leakage does not weaken the “actual” security at all. The serial number s is output to both parties 
(see below), and the attribute vector aq, is input by the operator and output to the user. Hence, if any of 
these parties is corrupted, the adversary learns this information anyway. This early leakage ahead of time is 
only a concession to the final implementation to enable the simulation of messages in the correct order. 
This unveils the user’s identity, but we do not guarantee that for double-spenders (cp. text body). 

Picking the upcoming fraud-detection IDs randomly asserts untrackability for honest users. For corrupted 
users, we do not (and cannot) provide such a guarantee and the fraud-detection ID might be chosen 
adversarially (cp. text body). 


a 


Figure 4.10: The Functionality fpc (cont. from Fig. 4.1) - Task Deposit, Part 1 
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Functionality 7%). (cont.) - Task Deposit, Part 2 


PoS input: (depositing, p) 
(9) b := PFE’ + p. 
10 € , leak (depositing, s, p, pi to the adversary,’ else lea. 
If O € PlDeorr, leak ( 9, pid.) he ad y,” else leak 
epositing,s, 9, pid», p) to the adversary,’ and (in both cases) ask for tags 
(d p, Pid, p) to the adversary,” and (in both cases) ask for tag 
(gs res Opp) that have not previously been used, or—if pidy € PLD coxr—also 
accept a non-unique wgs- 
(11) Append (sP!*", sp, x, A, pid, pide, p, b, oq. Orcs Opp) to TRDB. 
User output: (deposited, s, ap, p, b, pp) 
PoS output: (deposited, gg, rc, Opp) 


a 


N.b., for honest users 9 is a mere random number. The identity of the PoS cannot remain secret, because 
even an honest user might eventually be asked by the violation enforcer to prove its participation in this 
transaction. 

N.b., the corrupted operator eventually collects all recalculation tags and thus the adversary learns the price. 
If the PoS is corrupted, we cannot guarantee double-spending detection. 


Figure 4.11: The Functionality fpc (cont. from Fig. 4.1) - Task Deposit, Part 2 


The new balance bis calculated and the adversary is asked to provide a double-spending tag 
Ogs, a recalculation tag c, and a prove-participation tag cy. These tags may depend on the 
current serial number s, the current fraud-detection ID ¢ and the identity of the involved PoS 
pidp. We stress that both IDs (s, 9) have been freshly and uniformly drawn and thus do not 
unveil anything useful information-theoretically. Finally, the new transaction record trdb is 
stored in TRDB. Note that all information leading to the new wallet state except for the price p 
and the tags (ws, Wrc» pp) came from data internally stored in fpc itself and can therefore 
not be compromised. The serial number s, the current PoS' attributes ap, the price p and the 
updated balance b are output to the users so they may check they received the expected amount 
of points. As before, 74, does not really use the tags, but only records and outputs them again. 
For a discussion of the tags see Section 4.1.2. 

We now discuss the omitted cases of the task Deposit, which deal with corruption or misbe- 
havior. 

If in Step 6 the map f(A, x) is undefined as above, but the user is corrupted, the fraud- 
detection ID ¢ is not independently and uniformly drawn, but chosen adversarially. Similar to 
the task IssueWallet (cp. Section 4.3.1), this may infringe upon the unlinkability of the user's 
transactions. But we do not give any such guarantees for corrupted users. Also, this may lead 


to a premature abort (cp. Step 7), if the adversary chooses a y € blø which is blacklisted. 
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In Step 6 the map fa(A, x) will be defined, if the user commits double-spending or if fraud- 
detection IDs have been precalculated and prefilled for blacklisting purposes (cp. Section 4.4.2). 
Remember, the wallet ID A and transaction counter x corresponds to the tree and depth of 
a transaction node. In this, case Zp, assigns the same fraud-detection ID ¢ to the current 
transaction record in order to preserve consistency. Also, the set of all previous double-spending 
tags QU which have been recorded for transactions of the same wallet and transaction counter 
together with the user's identity are leaked to the adversary. The adversary replies with a 


proof of guilt z which is internally recorded by Zaye. 


The latter two steps fix an oversight in [Nag+20]. To understand them we need to skip ahead. 
The proof of guilt z is some kind of digital “evidence” which allows the operator to prove to 
any other party that the particular user is a fraudster and has committed double-spending. 
To enforce soundness, consistency and protection against false accusation of innocent users, 
fpc internally manages the map fy which records pairs of user identities and proofs of guilt. 
Usually, these proofs of guilt are not directly obtained via Deposit in case of a double-spending, 
but their generation is deferred to the utility task DetectDS (cp. Section 4.4.1). The validity 
of the proofs of guilt can be checked by any party using VerifyGuilt (cp. Section 4.4.1). This 
three-step approach is necessary, because misbehaving users might commit double-spending 
at different PoSes which are offline and only after these PoSes have synchronized their state 
with the operator, the operator is actually capable of detecting double-spending later. However, 
in a real implementation (at least in our implementation) the environment which guides all 
parties can create a valid proof of guilt as soon as a (even honest) user has committed double- 
spending. The environment simply runs the real code of DetectDS in its own head without 
actual calling DetectDS. The proof of guilt is perfectly valid and does not contradict the 
protection against false accusation (because the user has indeed committed double-spending), 
but has nevertheless not been output by DetectDS. On a high-level the environment can do so, 
because it instantly knows which users commit double-spending and does not depend on a 
periodically synchronization of information. To enable consistent replies by VerifyGuilt for 
these yet valid and legitimate but not system-generated proofs, Jape also needs to generate such 
a proof of guilt at the very moment when double-spending occurs. We stress that (1) this proof 
is not being output but only kept internally (direct output would preclude offline capabilities) 
and (2) misbehaving users immediately loose their anonymity as soon as they commit double- 
spending and not until DetectDS is invoked. This has been overlooked in [Nag+20] as the 


synchronization of state has not formally been defined but explained on a hand-waving level. 


Lastly, if the operator is corrupted Apc will not only leak (s, p, pidp) to the adversary but 
also the price p (cp. Step 10 in Fig. 4.11). Opposed to the leakage of the random numbers s, 
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$9, this might lead to an actual loss of unlinkability, but it is the best we can hope for, if the 
operator is corrupted. Although we do not stipulate how a recalculation tag c. looks like, 
because this is specific to the implementation, the recalculation tag enables the operator to 
recalculate the balance of a wallet, i.e. it acts like a digital invoice (see also RecalculateBalance 
in Section 4.4.3). Hence, it is quite reasonable that this tag encodes the price of a transaction 
among other things. If the operator is corrupted, the price cannot be kept secret from the 
adversary. Admittedly, the additional leakage of the price is a rather small detail, but again, 
has been overlooked in [Nag+20] as the synchronization of state has not spelled out and thus 


has not been part of the simulation-based proof. 


4.3.3 Disbursement 


As Disburse (cp. Fig. 4.12) is very similar to the task of Deposit, we will refrain from describing 
it again in full detail but rather just highlight the differences to Deposit. 

Please remind, that Disburse is designed with the post-payment scenario from Section 2.3.3 in 
mind. In other words, disbursement of points means to clear the recent balance and invalidate 
the wallet. Alternative definitions are discussed below. 

The first difference is that it is conducted with the operator rather than an PoS and no 
blacklist is taken as input as we do not want to prevent any user from clearing the balance. 
Disburse is identifying for the users to allow the operator to invoice them and check if they 
(physically) pay the correct amount. Also, the users do not obtain a new serial number as part 
of their output, because the transaction entry is supposed to be a leaf node. Nonetheless, a 
serial number is internally drawn and associated with the transaction. Instead of obtaining 
a price from the operator the recent balance is used and the price p := —bbill is part of the 
output to the operator. The prove-participation tag is omitted, but double-spending tag and 
recalculation tag are still kept, because Disburse is identifying for the user and hence there is 
no point in a separate prove-participation tag. Also note, that the leakage to the adversary 
is asymmetric to the leakage in Deposit and does not consider an extra case for a corrupted 
operator, because the operator directly participates in Disburse and learns the current price 
p = —bbill as part of the output (cp. Step 7 in Fig. 4.12 vs. Step 10 in Fig. 4.11). 

Alternative Definitions To realize the other scenarios from Sections 2.3.1 to 2.3.3 Disburse 
could be modified in several aspects. Each of these options make Disburse more similar to 


Deposit: 


2 Of course, this depends on the pricing model. If there is only a single, constant price, the additional leakage does 


not bear any information. 
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Functionality 7,,, (cont.) - Task Disburse 


User input: (disburse, sP!*V) 
(1) If RegisterOp has not yet been run, output 1 and abort. 
(2) Select (+, sPIeV, gPrev. xPrev, APIS", pid, y, pid”, -, DPYEY, ....-) € TRDB with 
S ,pi eing the unique key. 
(sPF°Y, pid, ) being the unique key. 
Operator output: (disbursing, pid.) 
Operator input: (disbursing) 


(3) Pick serial number s È S that has not previously been used. 
(4) Set A := AP! and x := xPI** + 1. 
(5) If fa (A, x) is already defined: 


(a) Set := fg (Ax). 


to the adversary“ and ask for a proof of guilt 7 € II for that f; (pid, 7) = NOK 
has not yet been defined. 


(c) Set f; (pid, ,, 7) = OK. 
Else: 
(a) Pick fraud-detection ID Q È 5 that has not previously been used, or—if 


pid4, € PIDeorr— leak (disbursing) to the adversary and ask for fraud- 
detection ID ¢ that has not previously been used.” 


(b) Append f(A, x) :— pto fo. 
(6) pbill .— pprev. 
(7) Leak (disbursing, s, p) to the adversary‘ and ask for tags (wg,, rc) that have not 
previously been used, or—if pido € PID.orr also accept a non-unique wgs." 
(8) Append (sP'*", s, y, x, À, pid, pido, —pbill 0, Ods» res L) to TRDB. 
User output: (disbursed, pbill) 
Operator output: (disbursed, bP, wg, Ore) 


+ Tf this does not exist, abort. 


Leaking previous double-spending tags of sibling nodes is a concession to enable consistent simulation. This 
may infringe on a user’s privacy, but we do not guarantee that for double-spenders (cp. text body). 
Picking the upcoming fraud-detection IDs randomly asserts untrackability for honest users. For corrupted 
users, we do not (and cannot) provide such a guarantee and the fraud-detection ID might be chosen 
adversarially (cp. text body). 

N.b., for honest users p is a mere random number. Also the leakage here is asymmetric to Deposit, because 
the operator itself participates in this task. 

If the operator is corrupted, we cannot guarantee double-spending detection. 


a 


Figure 4.12: The Functionality fpc (cont. from Fig. 4.1) - Task Disburse 
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(1) Disburse could also be executed with a PoS. 


(2) Instead of being identifying for the user, only the user's attributes could be output to the 
operator/PoS. Surely, in this case the blacklist should again be re-included into the input 


and checked. Also, the prove-participation tag is required again. 


(3) Instead of using the previous balance as the new price, the price could be determined by 
the operator/PoS the same way as in Disburse. In this case the next item also needs to 


be considered. 


(4) To ensure that the wallet is not overdrawn, the previous balance is output to the oper- 
ator/PoS before the operator/PoS inputs the price and the operator/PoS aborts, if the 
previous balance is no sufficiently high. Alternatively, %,,. internally checks that the 
balance is high enough after operator/PoS has input the price and outputs a special error 
message to both parties. However, this requires costly range proofs [CLZ12; CCso8] in 


the implementation (cp. Section 6.2.7). 


4.4 Utility Tasks 


To obtain a feature complete anonymous point collection system we also provide the utility 
tasks DetectDS, VerifyGuilt, BlacklistWallet and ProveParticipation. All of those tasks deal 


with different aspects arising from fraudulent user behavior. 


4.4.1 Double-Spending Detection and Guilt Verification 


Due to our requirement to allow offline PoSes, misbehaving users are able to fraudulently 
deposit points on outdated states of their wallets. This double-spending cannot be prevented 
but must be detected afterwards. To ensure this, %,,. provides the tasks DetectDS (cp. Fig. 4.13) 
and VerifyGuilt (cp. Fig. 4.14). 

DetectDS is a one-party task executed by the operator and takes two double-spending tags 
Ogg, 4, as input. Again, we first describe the case in which all parties are honest and in which 
the environment only inputs genuine double-spending tags, i.e. tags that have been output by 
Deposit or Disburse before (cp. Definition 4.1). 

First Fape looks up the corresponding transaction nodes trdb, trdb’. These exist, because Ods 
w4, are genuine. The condition in Step 2 in Fig. 4.13 simplifies to the question whether the 
fraud-detection IDs q, p’ match or not. If they are not equal, the given double-spending tags 
do not belong to transactions that have a common predecessor, in other words the double- 
spending tags do not attest double-spending. In this case the adversary is asked for a user 


identity pid, ,, a proof of guilt z and a result bit result. However, the result bit it not used at 
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Functionality Apc (cont.) - Task DetectDS 
Operator input: (detect_ds, wy,, 004.) 
(1) Pick trdb + trdb’ in TRDB such that trdb = (., 0.5 pid, pid, 5 09s ` ') and 
trdb’ = (449, ` pid; y» pido, $550 as j. 
If no record trdb, trdb € TRDB for Was» Qs resp., exists or Wg, = Dr set 
trdb = trdb’ = L. 
(2) If trdb = L or trdb’ = Lor ọ + ¢': 
(a) Leak (detecting ds, wg,, QA.) to the adversary and obtain (pid, 7, result). 
(b) If f(pidq; 2) has already been defined, do nothing, else if f; (pid, 7) is 
undefined and pida, € PLD corr, set fj (pid, ,, 7) :— result, else overwrite 
(pid. m) = (1.1). 
Else (i.e. distinct trdb, trdb’ exist and y = y” holds): 
(a) Leak (detecting ds, pid,,) to the adversary ^ and ask for a proof z + | for 
that f; (pid, , 7) = NOK has not yet be defined previously. 
(b) Set f; (pid, 7) := OK. 
Operator output: (detected ds, pid, |, 7) 


* Nb, pid = pid, holds. 


Figure 4.13: The Functionality fpc (cont. from Fig. 4.1) - Task DetectDS 


Functionality 7,,. (cont.) - Task Verify Guilt 


Party input: (verify_guilt, pid, 1) 
(1) If f. (pid, 7) is defined, then set result := f; (pid, 7). 
(2) If f; (pid, ,, 7) is not defined and pid,, € PID corr, then leak 
(verifying guilt, pid, ,, 7) to the adversary and obtain result result. 
(3) In any other case, set result := NOK. 
(4) Append (pid, ,, 7) > result to fy. 
Party output: (verified guilt, result) 


Figure 4.14: The Functionality fpc (cont. from Fig. 4.1) - Task VerifyGuilt 
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all, but Fape unconditionally returns the invalid output (1, L). Note, we assume the user to be 
honest, i.e. pid, € PLD corr holds. This branch asserts protection against false accusation for 
honest users. If the fraud-detection IDs are equal, there has indeed been a double-spending 
incident. In this case the user's identity is leaked to the adversary and the adversary is asked to 
provide a proof of guilt z. This proof of guilt is then recorded as being valid for the fraudulent 
user. This branch asserts completeness. 

We now discuss the remaining corner cases. If no transaction exists for at least one of the 
given double-spending tags, i.e. at least one of the double-spending tags is a fake tag, the first 
branch is applied and the adversary may decide about the user and the result. Also, if the 
denoted user is corrupted, the result is adopted unaltered. This may result into a valid proof 
of guilt although the user has not committed double-spending, but protection against false 
accusation is not guaranteed for corrupted users. Moreover, if f; (pid, ,, 7) has already been 
defined, the result is not changed. This asserts consistency across multiple invocation and a 
proof of guilt that has been invalid for a particular user cannot spontaneously become valid 
and vice versa. 

Double-spending detection is complemented by VerifyGuilt. It is also a one-party task but 
can be performed by any party. To put it simply, VerifyGuilt checks if the given proof of 
guilt x is internally recorded as being valid for the particular user ID pid, ,. Again, this over- 
simplification turns out to be unrealizable, because consistency with respect to fake proofs and 
corruption of parties must be taken into account. 

First, Verify Guilt checks if this particular pair (pid, ,, 7) has already been defined and outputs 
whatever has been output before. This ensures consistent answers across different invocations. 
If (pid, , 7) has neither been issued nor queried before and the affected user is corrupted, the 
adversary is allowed to decide if this proof of guilt should be accepted. This reflects that we do 
not protect corrupted users from false accusations of guilt. If the user is honest and (pid, ,, 17) 
has neither been issued nor queried before, then the proof of guilt is marked as invalid. This 
protects honest users from being accused by fake proofs which have not been issued by the 
ideal functionality itself. Finally, the result is recorded for the future and output to the party. 
This possibility of public verification is vital to prevent the operator from wrongly accusing 
any user of double-spending and should for instance be utilized by the dispute resolver before 


it agrees to blacklist and therefore deanonymize a user on the basis of double-spending. 


4.4.2 Wallet Blacklisting 


The task BlacklistWallet (cp. Fig. 4.15) is run between the operator and dispute resolver. The 
operator inputs a blacklisting tag cj which the operator has obtained at the end of IssueWallet 
to denote the wallet the operator wishes to blacklist. If BlacklistWallet succeeds, the operator 
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Functionality Apc (cont.) - Task BlacklistWallet 


Operator input: (blacklist wallet, œp) 


(1) Set A:= fo, Gy. 

(2) Let pid, the user PID that is associated to any (-,-,-, A, pidqp 55555) € TRDB.* 

(3) If O is corrupted and (pid,,, A) is undefined, leak blacklisting wallet to the 
adversary and ask for (pid, , 1) with a À not used in TRDB.’ 


4 idg, A) is undefined, output (blacklisted wallet, Ø) to operator and halt. 
If (pid, , A) is undefined, output (b ) p d hal 
Dispute resolver output: (blacklisting wallet) 
Dispute resolver input: (blacklisting wallet, pid; /) 
5) If pid,, + pid;,,, output (blacklisted wallet, Ø) to operator and halt. 
piaq; + Play, p p 
(6) x, := max{x | fo(A, x) is already defined}. 
(7) For x € {x} + 1,... , bound! 
(a) Pick y È ð that has not previously been used, or—if pid, € PID¿oy—leak 


(blacklisting wallet, A, x) to the adversary and ask for fraud-detection ID 9 
that has not previously been used. 


(b) Append (A, x) > ọ to fo. 
(8) blo, = {fol A, x) | 0 = x < Xbounat: 
Dispute resolver output: (blacklisted_wallet) 
Operator output: (blacklisted wallet, bla, ) 


^ Nb: pid, is constant across each trdb € TRDB for a fixed wallet ID A, hence pid, is well-defined. 
^ Only an honest operator is guaranteed to get a blacklist for the “correct” wallet. N.b., A is never output 
anywhere, hence the chance to meet an actually existing A is neglible. 


Figure 4.15: The Functionality fpc (cont. from Fig. 4.1) - Task BlacklistWallet 


receives a set of past and upcoming fraud-detection IDs blg, as output so it may add them to 
the PoS blacklist bla. The dispute resolver inputs a user identity pid, to signal its consent to 
blacklist a wallet of that user. We assume that both parties negotiated on the user identity 
out-of-band before the task starts. For example, the operator might have presented a valid 
proof of guilt to the dispute resolver for that user or the user agreed to be blacklisted due to 
a lost wallet. Note, that IssueWallet (cp. Section 4.3.1 and Fig. 4.9) is identifying for the user. 
Hence, the operator knows which blacklisting tag are associated to which user. 

Again, we start the description for the “good” case, i.e. for an honest operator that inputs 
a genuine blacklisting tag and an honest user. (N.b.: The dispute resolver is assumed to be 
always honest.) In a nutshell, 9,,. first determines the wallet ID A the blacklisting tag has 


been output for and looks up the associated user ID pid,, from the transaction database. If the 
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Functionality 9). (cont.) - Task RecalculateBalance 


Operator input: (recalculate_balance, blg, 2,.) 
(1) If RegisterOp has not yet been run, output L and abort. 


(2 ) genuine „_ = {Ore EQ | 3 trdb = C 1575757879757 77, Ores ) € TRDB} 

(3) Ofake = Qne X peste 

(4) € = {(s, p) | 3 trdb = (5,9, Diss res) € TRDB A Gye € gone AQE bl 

(5) Set om = Xis pez P 

(6) If Qfake — = @, then set pieviate := 0, else leak (recalculating | balance, ble, Qfake) to 


the adversary and obtain deviating price pdeviate, 
(7) pbill .— pbill y pieviate 


Operator output: (recalculated_balance, bPill) 


Figure 4.16: The Functionality fpc (cont. from Fig. 4.1) - Task RecalculateBalance 


dispute resolver inputs the same user ID, fpc checks how many values of fg(A, -) are already 
defined and extends fg to the first Xona fraud-detection IDs, with Xx oung being a parameter 
we assume to be greater than the number of transactions a user would be involved in within 
one billing period. To that end, yet undefined fraud-detection IDs fo(A, x) with x € Xhoung are 
uniquely and randomly drawn. This ensures that upcoming transactions use predetermined 
fraud-detection IDs that are actually blacklisted. 

If a corrupted operator inputs a fake blacklisting tag the adversary is asked to provide a 
user ID pid,, and a wallet ID A which must not belong to an existing wallet. In this case the 
operator might eventually receive a set bl, of x,ounq random fraud-detection IDs, but these 
are never used in any task. If the user is corrupted, the adversary is allowed to choose the 
fraud-detection IDs. 


4.4.3 Balance Recalculation 


The task RecalculateBalance (cp. Fig. 4.16) is a one-party task executed by the operator. The 
operator inputs a set of fraud-detection IDs blg and a set of recalculation tags Q,,. The result 
is the accumulated sum of all transaction for which an associated recalculation tag has been 
provided and which are selected by a matching fraud-detection ID. Note that although the sum 
may contain the prices of transactions and wallets that have already been cleared, this does 
not falsify the value of bPill as every successful execution of Disburse creates an entry with the 


amount that was disbursed as negative price. 
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The intended usage is to recalculate the balance bil of individual wallets or all wallets of a 
particular user. To this end, the operator needs to input a set b/g of fraud-detection IDs that 
equals a complete or otherwise unaltered set b/g, as it has been output by Blacklist Wallet (cp. 
Section 4.4.2) or a union thereof. Figuratively spoken, the intention is that operator handles 
the output set blg, of BlacklistWallet as monolithic, opaque blocks and the input set blg is a 
union of these. Still, there is no guarantee that the operator inputs the union of “complete” sets 
blo. Moreover, the set blg and the set Q,. could also contain fake entries. In the latter case, 
the adversary is allowed to modify the result by an offset pdeviate without any restrictions. 

In [Nag+20] the tasks BlacklistWallet and RecalculateBalance are a combined single task 
(called BlacklistUser there). The task has been split, because the dispute resolver is only 
required for the actual blacklisting part, but not for the recalculation part and keeping these 


parts separately make this clear. 


4.4.4 Prove of Participation 


This is a two-party task involving a user and the violation enforcer (cp. Fig. 4.17) and assumed to 
be conducted with every user which has been physically identified by the violation enforcer's 
and is suspected of having avoid Deposit. It allows well-behaving users to prove their successful 
participation in a transaction with the PoS at which the identification took place, while the 
fraudulent user will not be able to do so. 

The violation enforcer inputs the identity of the suspected user pid, ,, the identity of the PoS 
pid, and a set Q p of prove-participation tags which are related to the investigated transaction 
in a timely and spatial manner and must be provided by the PoS which reported the incident. 
The user inputs a single prove-participation tags cy after having learned which PoS and 
potential transactions are under investigation. Using the "right" wp, allows users to prove their 
innocence. 

Again, we describe the "good" case (all parties are honest, the input tags are genuine) first. 
If the provided prove-participation tag «yj is in the set of investigated prove-participation 
tags Qpp and if the recorded user and PoS identities pido, pid of the transaction which is 
associated to Opp match the identities under investigation, then the violation enforcer obtains 
a positive result, else a negative result. 

If the prove-participation tag is a fake tag and if both the user and the PoS are corrupted, 
then the adversary may decide on the result. This may lead to a false positive result, but this is 
an inherent restriction of our setting with offline capabilities. Remember that the task Deposit 
is a two-party task between the user and the PoS. If the suspected user and the PoS are both 
corrupted and collude, the PoS is able to give a false testimony. 

If the violation enforcer is corrupted, the prove-participation tag cp, is leaked to the ad- 


versary. We like to stress that this is not only a peculiarity of our proposed implementation, 
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Functionality %,p. (cont.) - Task ProveParticipation 


Violation enforcer input: (prove participation, pid, pid, App) 


(1) If RegisterUser for pidq; or RegisterPOS for pidp have not yet been run, output L 
and abort. 


User output: (proving participation, pid, pp) 
User input: (proving_participation, Opp) 


(2) If Opp € y, then output (proved participation) to U, output 
(proved participation, NOK) to VE and halt. 


(4) If pid y, € PLD or; leak (proving participation, Opp) to the adversary. 
(5) If trdb is undefined and {pidq;, pid] € PLD corr: 


(a) Leak (proving_participation) to the adversary and obtain result. 
Else (i.e. trdb is defined or pid, or pid, is honest): 
(a) If pid, = pid, and pid, = pidp hold,“ then set result := OK, else result := NOK. 
User output: (proved_participation) 
Violation enforcer output: (proved_participation, result) 


* N.b, if trdb is undefined, then pid), = L holds which implies that pid,, + pid}; and result = NOK follow. 


Figure 4.17: The Functionality fpc (cont. from Fig. 4.1) - Task ProveParticipation 


but inherent to the task. Assume that the user is able to successfully prove its participation. 
Although the violation enforcer only learns a single result bit, this is sufficient to find out which 
Opp € Qpp the user has input. The violation enforcer could repeatedly run the task and summon 
the user to prove its participation for a descending sequence of bi-sected sets until the last set 
only contains a single tag. Nonetheless, this does not affect the anonymity or unlinkability of 
any other transactions. 

We are aware of the fact that this definition leaves room for an “attack” or more precisely an 
abuse by the PoS. The PoS triggers the violation enforcer to identify the offending user out-of- 
band (e.g. by taking a photo) and the same PoS also provides the set O5, of prove-participation 
tags. Of course, the intended idea is that this set encompasses prove-participation tags which 
are somehow’ related to the whereabouts of the incident. However, the PoS could intentionally 
provide a wrong set Oy, which misses the relevant tags and thus make it impossible for the 


(innocent) user to exculpate themselves. This flaw cannot be fully resolved, but mitigated. A 


> We are intentionally vague here, because what the precise meaning of “whereabouts” depends on the concrete 


deployment. 
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possible solution requires the introduction of another ideal functionality* and would very much 
deviate from [Nag+20]. This extension is discussed in Chapter 10. Moreover, note that a PoS 
cannot use this “attack” to target a specific user and the strategy poses the risk that not only 
a single, but multiple users are (falsely) found guilty. (Because the PoS cannot know which 
prove-participation tags should be omitted from O5, and thus may drop too many.) However, 
as for a single transaction only one user can have been cheating, such an impossible result 
should be noticed and lead to an audit of the system. But this out of the scope of the security 
model. 


* This functionality needs to encapsulate the concept of “whereabouts”. 
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In this chapter we discuss some aspects of the definition of fpc from Chapter 4. 

Most importantly, we argue why apc captures an ideal model of a secure and privacy- 
preserving anonymous point collection scheme. Especially, we illustrate how the high-level 
objectives of an anonymous point collection scheme (cp. Section 2.6) are reflected in fpe- The 
properties (P1) to (P8) are consolidated under the term Operator Security and Correctness and 
discussed in Section 5.1, while properties (P9) to (P11) are summed up under User Security and 
Privacy in Section 5.2. Instead of defining a game-based security definition for each of these 
properties and then show that the yet to be defined implementation fulfills these games, we 
formalize the properties and show that the ideal functionality fulfills the properties. 

Section 5.3 discusses some aspects of the user/PoS attributes, the leakage and the pricing 
function with a focus on anonymity. This section clarifies what kind of anonymity is considered 
in this thesis and likewise important what is not guaranteed. 


Finally, Section 5.4 regards two aspects of the definition with nearby alternative approaches. 


5.1 Operator Security and Correctness 


At the bottom line, operator security, especially correctness of billing, follows from the fact 
that apc represents an incorruptible accountant which manages all wallets and their associated 
transactions in a single, pervasive database TRDB. For example, in Deposit and Disburse 
a (possibly malicious) user only inputs a serial number to indicate which previous wallet 
state should be used. All relevant information is then looked up by %p. internally. Similar 
observations hold for all other tasks. 

Typically, an ideal functionality is a rather simple object (e.g., a commitment, an oblivious 
transfer, a coin toss) and it is mostly obvious from its definition that it captures the right notion 
of security and correctness. In contrast, our ideal functionality fpc is already a complex system 
on its own with polynomially many parties that can reactively interact forever, i.e., fapc itself 
has no inherent exit point except that at some point the polynomially bounded runtime of the 
environment is exhausted. 

As already described in Section 4.1 the set of transactions TRDB is best visualized as a 


description of a directed graph with labeled nodes and edges. Section 4.1 has also brought 
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forward the intended interpretation of particular structural properties of this graph (e.g. wallets 
correspond to trees; see there and in particular cf. Fig. 4.3). In this section we show that the 
definition of Zap, (cp. Sections 4.2 to 4.4) actually fulfills this intention. We give a series of graph- 
theoretic lemmas to prove that the desired structural properties hold after each invocation of a 
task of fapc as a sort of invariant and thereby assert that there is no execution of %p. which can 
deviate. These lemmas include that the graph as a whole is a directed forest where each tree 
corresponds to a wallet ID A, double-spending corresponds to branching and different wallet 
states have the same fraud-detection ID q if and only if they have the same depth in the same 
tree. Moreover, these lemmas a closely associated to the desired properties of an anonymous 


point collection scheme (cp. Section 2.6). 


Definition 5.1 (Ideal Transaction Graph) The transaction database TRDB = {trdb;} with 
trdb = (sPI*v, s, (p, x, A, pid, pidp, p, b, Ods Orc Opp) € TRDB (5.1) 


is a directed, labeled graph with vertices identified by s, edges identified by (sP'°”, s), vertex labels 
given by (9, x, A, pid, , b) and edge labels given by (pidg, p, @gs, Orce, pp). This graph is called the 
Ideal Transaction Graph. 


Lemma 5.2 (Forest Structure of the Ideal Transaction Graph) The Ideal Transaction 
Graph TRDB is a forest. 


Pnoor TRDB is a forest, if and only if it is cycle-free and every node has in-degree at most 
one. A new node is only inserted in the scope of IssueWallet, Deposit or Disburse. Proof by 
Induction: The statement is correct for the empty TRDB. If IssueWallet (cp. Fig. 4.9) is invoked, 
a new node with no predecessor is inserted. Moreover, the serial number s of the new node is 
randomly chosen from the set of unused serial numbers, i.e., it is unique and no existing node 
can point to the new node as its predecessor. If Deposit (cp. Figs. 4.10 and 4.11) or Disburse (cp. 
Fig. 4.12) is invoked, a new node is inserted that points to an existing node. Again, the serial 
number s of the new node is randomly chosen from the set of unused serial numbers, i.e., it is 
unique and no existing node can point to the new node as its predecessor. Hence, no cycle can 
be closed. Since the only incoming edge of a node is defined by the stated predecessor sP'*" 


(which may also be L), each vertex has in-degree at most one. " 


Lemma 5.3 (Tree-wise Uniqueness of the Wallet Identifier) The wallet ID A maps one- 


to-one and onto a connected component (i.e., tree) of the Ideal Transaction Graph. 


[ 


Pnoor “ <=”: Let trdb; be an arbitrary node in TRDB and A be its wallet ID. Furthermore, let 


trdb; be the root of the tree containing trdb;. Then on the (unique) path from trdb; to trdb,, 
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every node apart from trdb; was inserted by means of either Deposit (cp. Figs. 4.10 and 4.11) or 
Disburse (cp. Fig. 4.12), both of which ensure the inserted node has the same 4 as its predecessor. 
By induction over the length of the path, trdb; has the same wallet ID as trdb; and hence the 
wallet ID is a locally constant function on TRDB. 

“ == ”: For contradiction assume there are two nodes trdb; and trdb; with equal wallet 
IDs A; = Aj in two different connected components. Pick the root nodes trdb; and trdb; of 
their respective trees. By “ <=” it we get Af = 4 = Aj = Aj, ie. the root nodes have equals 
wallet IDs, too. Both root nodes are inserted in the scope of IssueWallet and the wallet ID is 
randomly drawn from the set of unused wallet IDs, i.e., they cannot both have the same wallet 


ID. Contradiction! = 


Lemma 5.4 (Tree-wise Constness of the User PID) Within a tree of the Ideal Transaction 
Graph the PID pid.,, of the corresponding user is constant. 


Proof Same proof as “ <= ” in the proof of Lemma 5.3. " 


In other words, Lemma 5.4 states that a wallet (a tree in TRDB) is always owned by a distinct 


user. But a user can own multiple wallets. 
Lemma 5.5 (Layer-wise Uniqueness of the Fraud-Detection Identifier) 


(1) Within a tree of TRDB, every node trdb = (sP'*", s, p, x, À, pid, pid, p. b, Ody Ores Opp) 
has depth x and all nodes of the same depth in the same tree have the same fraud-detection 
ID q. Conversely, nodes with the same fraud-detection ID are in the same tree and have the 


same depth within this tree. 
(2) fo is injective. 


Proor Proof by Induction. The statement is true for the empty TRDB. In the scope of 
IssueWallet (cp. Fig. 4.9) a new root node is inserted, IssueWallet sets x := 0 and an un- 
used ¢ is chosen. In the scope of Deposit or Disburse, x is calculated as x := xP!*" + 1, where by 
induction xP'*Y is the depth of its predecessor. With respect to g we note that when inserted, 
every node gets as fraud-detection ID the value stored in fg(A, x) which only depends on the 
node's wallet ID and depth. When this value is set (in either IssueWallet, Deposit, Disburse or 
BlacklistWallet, cp. Figs. 4.9 to 4.12 and 4.15) it is chosen from the set of unused fraud-detection 


IDs and therefore unique for given A and x. " 


So far, the lemmas above have not had a concrete semantic interpretation in terms of an 


anonymous point collection scheme. This changes for the upcoming lemmas. 
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Lemma 5.6 (Billing Correctness) Let trdb = (sP!*,s, p, x, À, pida, pide, p, b, os, Wrc, Opp) 
be an arbitrary but fixed node. If trdb is not a root let trab?" = (sprev,prev, gPI€V, prev. prev, 
A, piday pun. pare, pprev. oY, ke ale obp ) be its predecessor. Then b = bP'® + p holds for 


non-root nodes and p = 1, b = 0 for root nodes. 
Pnoor Same induction argument as in proof of Lemma 5.5. " 


Lemma 5.7 (Double-Spending Detection Completeness) Let the operator be honest and 
let a user (possible malicious) with PID pid, , have committed double-spending while interacting 
with two honest PoSes with PIDs pid,, and pid. Let wgs, 04, denote the corresponding double- 
spending tags that are output at the PoS’ side. 


(1) The task DetectDS outputs (pid, y, z) with x + L upon input of (was, 0.) 
(2) The task VerifyGuilt returns OK upon input of (pid, , 7). 


Proor (1) The honest PoSes imply that c, @/, are unique, especially wgs + w4, holds (cp. 
Step 10 in Fig. 4.11). Let trdb, trdb denote the recorded transaction entries and q, q' 
the associated fraud-detection IDs. Lemma 5.5 implies g = y”. Hence, the else-branch 
of DetectDS (cp. Step 2 in Fig. 4.13) applies, f; (pid, , 7) := OK is set and the statement 
follows. 


(2) Due to Item (1) f (pid, 7) := OK holds. This is the return value of VerifyGuilt (cp. 
Fig. 4.14). = 


Lemma 5.8 (Correctness of Wallet Blacklisting and Balance Recalculation) Let «yj 
an arbitrary but fixed blacklisting tag which O has received as output from IssueWallet for a 
wallet with ID À. Let the operator O and all PoSes which interacts with this wallet be honest. 
Under the assumption that the wallet is used in less than Xpoung transactions, i.e., in less than 


Xyoung invocations of IssueWallet, Deposit and Disburse, the following two statements hold: 


(1) The set blo, returned to O by BlacklistWallet on input œp for a successful execution” 


contains all fraud-detection IDs that have ever been used for the wallet. 


(2) Any invocation of Deposit on input of a serial number sP'** which belongs to this wallet 


and on input of a blacklist bla 2 blg, aborts with blacklisted wallet. 


* The PoS might be the same in both interactions. 


We postulate that the dispute resolver agrees to blacklist the affected user. 


2 
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(3) RecalculateBalance returns the accumulated sum of all transaction of the wallet within 


Deposit and Disburse, if RecalculateBalance is called with input (blo, Qrc) for a set O. 
which contains at least all recalculation tags that have been output to the PoSes and no fake 


recalculation tags. 


PROOF (1) As œ is genuine, i.e. is output of a successful execution of IssueWallet, A := 


(3) 


fo, on) is defined and the set TRDB; C TRDB of all transaction entries trdb = (..., À, ...) 
corresponding to A is not empty. The statement is a consequence of Lemma 5.5. The 
depth of the tree described by TRDB, is given by x, := max{x | fg(A, x) + 1j. If the 
associated wallet hast been used in less than x, „und transaction, then the depth x; is 
smaller than X, Jung: The set of used fraud-detection IDs is given by { f(A, x) 10 € x € x3} 
which is a subset of bl, := {fo(A, x) 10 € x € Xbound? 


Let sP'*Y denote the serial number for which Deposit is invoked and let trdbP""" = (., sPrev. 
prev 
holds. As BlacklistWallet has previously been called, y = f(A, xP" + 1) is already fixed. 
Moreover, y € blg, E blg holds and thus Deposit aborts. 


xPI*Y. A,...) be the corresponding transaction entry. By assumption xP'*" < xy ound 


By assumption Of2ke = Ø holds in RecalculateBalance and thus pleviate = 0 follows (cp. 
Step 6 in Fig. 4.16). Let 


Ey {(s, p) | trdb = (-,8,, À, Doves) € TRDB} (5.2) 
the set of all (s, p)-pairs for the wallet with wallet ID A under consideration. Let 
E {(s, p) | 3 trdb = (55,9, sss poss rc») € TRDBA Gye € cans AQ € blo} (5.3) 


be as in Step 4 of Fig. 4.16. We have to show that E; = £ holds. 


“E, € E”: Let (s", p) € £j and let trdb” = (-,8*, 0, A, s Dis @res) € TRDB be the 
corresponding transaction entry. y € blg = blg, follows by Item (1) and wrc € Qe 
follows by assumption. This yields trdb* € 3. 


m 


5, 2 &: Assume there is a (s*, p) € EN E; and let trdb* = (., 85,0, À ss Diss Opes) € 
TRDB the corresponding transaction entry. trdb* € E; implies A + A’. However, this 
means there exists x, x’ € {0,... ‚Xpounds S-t. f(A, x) = 9 = fo(A’, x’) and there exist 


condition is impossible and an immediate contradiction: fg is injective (cp. Lemma 5.5) 
and in Deposit as well as Disburse a unique recalculation tag «y, is selected (cp. Step 10 


in Fig. 4.11 and Step 7 in Fig. 4.12). " 
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We now discuss why the properties properties (P1) to (P8) are fulfilled by Faye. 


(P1) Owner-binding: Given the serial number sP'** of a previous wallet state, fpc checks that 
the associated wallet actually belongs to the calling user and thus has been legitimately 


issued to this user. 


(P2) Attribute-binding: As the attributes aqy, tp associated to the indicated transaction, resp. 


wallet, are internally managed by Fapc, the user is unable to claim his wallet contains 


any other information than it actually does. 
(P3) Balance-binding: This is a direct consequence of Lemma 5.6. 
(P4) Double-spending Detection: Follows from Lemma 5.7. 


(Ps) Participation Enforcement: This is handled outside the scope of fpc- As discussed in 
Chapter 2, we assume users to be physically identified by cameras, if they do not properly 


participate in Deposit. 
(P6) Blacklisting: A consequence of Lemma 5.8, Items (1) and (2). 
(P7) Accountability: Follows from Lemma 5.8, Item (3). 


P8) Renegade Expulsion: This is handled outside the scope of Ane by encoding a limited time 
E p p apc Dy 8 
of validity into the PoS' attributes (cp. Section 2.4). 


5.2 User Security and Privacy 


In this section we argue why 75. implements the properties (Pg) to (P11). As in the previous 


section, we first show two lemmas. 


Lemma 5.9 (Double-Spending Detection Soundness) Let the user with pid , be honest 


and not have committed double-spending. 
(1) The task DetectDS never outputs (pido, 17) with x + L. 


(2) For all x the task VerifyGuilt returns NOK on input (pid, , 7). 


Proor (1) The user has not committed double-spending. Lemma 5.5 implies that y + 9’ 
holds for all pairs of transactions trdb + trdb’ which are associated to pid,,. Hence, in 


Fig. 4.13 the first branch of Step 2 applies and Zap. outputs (1, L). 
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(2) The task VerifyGuilt first checks if f;(pid4,, z) has already been defined. f,(pidq,,7) 
is only defined in Deposit (cp. Step 6 in Fig. 4.10), Disburse (cp. Step 5 in Fig. 4.12), 
DetectDS (cp. Fig. 4.13) or VerifyGuilt (cp. Fig. 4.14). The assumption that the user 
has not committed double-spending immediately rules out the first two options and 
the Item (1) rules out the third option. If f,(pid;,, 2) has been defined by VerifyGuilt, 
then VerifyGuilt outputs the same result as in the previous invocation. Hence, w.l.o.g. it 
suffices to consider first time invocations of VerifyGuilt and to assume that f,(pid,,, zr) 
is undefined. In this case, VerifyGuilt returns NOK irrespective of the input (cp. Step 3 in 
Fig. 4.14). " 


Lemma 5.10 (Prove of Participation Completeness) Let the user be honest and wp, the 
prove-participation tag which the user has obtained as output from Deposit in an interaction with 
a (possibly malicious) PoS. Then, ProveParticipation returns OK upon input (pid, , pidp, Qpp) for 
a Qpp with wpp € App- 


Pnoor As the user is honest and wpp genuine, a corresponding trdb € TRDB has been recorded 
by an execution of Deposit. The statement follows from the definition of ProveParticipation 


(cp. else-branch of Step 5 in Fig. 4.17). = 


The information leakage that needs to be considered for an assessment of user privacy 
directly follows from the in- and output as well as the explicit leakage of the ideal functionality. 


We stress that we only care about privacy for honest, well-behaving, non-blacklisted? users. 


(Pg) Unlinkability: First note that the serial number of the previous transaction sP'*" is a 
private input of the user and never output to any party. After Deposit the PoS only 
learns the serial number s and fraud-detection ID ¢ of the current transaction which are 
both freshly, uniformly and independently drawn by 745. IssueWallet only outputs s 
and Disburse additionally outputs the final balance bP!!! (cp. Figs. 4.9 and 4.12). Hence, it 
is information-theoretically impossible to track an honest and well-behaving user across 
any pair of transactions using any of these numbers. The only “real” information leakage 
in Deposit is determined by the user's and the previous PoS’ attributes aq, and as 


which need to be assessed separately (see Section 5.3). 


(P10) Participation Provability: As discussed in Chapter 2 we assume that if users do not 


properly participate in Deposit, they are physically identified outside the scope of Faye. 


3 


Note that the operator may only blacklist users with the help of the incorruptible dispute resolver who only 
cooperates if the user has agreed or misbehaved. 
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Task Leakage 

pida, ay aplag ay’ p pH 
RegisterUser . 
IssueWallet . . . 
Deposit . . . . 
Disburse . (+) . . 
ProveParticipation . 


Table 5.1: Information an adversary learns about honest users. 


Lemma 5.10 asserts that suspected but inculpable users who successfully completed 
Deposit and are accidentally part of the investigation can prove their innocence. In 
ProveParticipation fpc only outputs a single bit whether the user has successfully par- 
ticipated or not. The violation enforcer who does not learn anything about any of the 


user's transactions beyond that. 


(P11) Protection Against False Accusation: Follows from Lemma 5.9. 


5.3 Impact of the Attributes and Leakage on the 


Privacy Level 


The ideal functionality provides unlinkability of transactions (cp. property (P9)) up to what 
can be deduced from user and PoS attributes and the leakage of the ideal functionality. As 
already discussed in Section 2.4, we assume these attributes to be sufficiently indistinct that 
they do not enable tracking of the user. This is not ensured within the scope of fpc» apart 
from outputs to the users, which enable them to check themselves that they are not identifying. 
Since we prove our realization psc to be indistinguishable from the ideal functionality Faye, it 
is ensured that an adversary attacking zpsc in the real world can only learn as much about a 
user as an adversary in the ideal model. 

Table 5.1 summarizes what an adversary learns about the users in each task. We omitted 
the serial number s and the fraud-detection ID ¢ in the table as these are independently and 
uniformly drawn randomness and thus cannot be exploited (see (P9) in Section 5.2). In all tasks 
except Deposit the user's identity pid., is leaked. The variables aq, ap, a and dg refer to 
attributes of the participating parties. The variable p denotes the price of a Deposit transaction, 
and bPill is the total debt the user owes at the end of the task Disburse. 
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Let’s call the period from the point of time at which a wallet is issued until the point of 
time at which its points are disbursed, the lifetime of a wallet.’ For every wallet’s lifetime, the 
operator collects all transaction information from every PoS. Hence, the operator eventually 


possesses two datasets: 


(1) A database of users that are identified by their PID pid,, together with their attributes and 
total balance Dill at the end of a wallet’s lifetime. This dataset comprises all information 


from every conducted task but Deposit. 


(2) A database of anonymous transactions during the wallet’s lifetime. This dataset stems 


from the Deposit tasks (cp. Table 5.1). 


With respect to practical privacy considerations one can naturally pose several questions: Can 
a single transaction be linked to a specific user? Has a user deposited points at a particular 
PoS? Can a user be mapped to a complete sequence of consecutive transactions? A final 
answer to these questions crucially depends on the concrete instantiation of the attributes aqy, 
ap and the pricing function but also on “environmental” parameters that cannot be chosen 
by the system designer such as the total number of registered users, the average number of 
transactions within the lifetime of a wallet, etc. An in-depth analysis would require plausible 
and justifiable assumptions about probability distributions for these parameters, and would 
constitute a separate line of research in its own right. 

In the following, however, we would like to elaborate a bit on the general aspects of the 
question, how a user can be linked to a wallet's transactions. This problem can be depicted as 
a graph-theoretical problem of finding a path in a directed graph. In short, the problem is to 
reconstruct the (unknown) ideal transaction graph TRDB from a given set of nodes without the 
edges. More precisely, a problem instance is given by a graph which consists of initial nodes, 
inner nodes and terminal nodes. Initial nodes correspond to root nodes of TRDB, represent 
IssueWallet transactions and are linked to users. Terminal nodes correspond to leaf nodes of 
TRDB, represent Disburse transactions and are also linked to users and final balances pbill Inner 
nodes represent the anonymous Deposit transactions in between. A directed edge connects 
two nodes if the target node is a plausible successor of the source node. Hence, the set of 
examined edges is a superset of the edges in TRDB. Especially, the graph is not a directed forest 
and the problem is to select a subset of those edges such that the “true” TRDB is reconstructed. 

The complexity of the task obviously depends on how much larger the superset of edges is 


compared to the size of the true set. Assuming that transactions can only occur at discrete 


*  N.b., the explanations are written with the running prime example of a post-payment scheme (cf. Sections 2.3.3 


and 2.3.4) in mind. Adopted considerations hold for the other scenarios. 
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points in time, the inner nodes can be ordered in layers. As a bare minimum, an edge is only 
plausible and thus contained in the superset, if the connected nodes have equal user attributes 
ayy, the attribute ab of the target node equal ag of the source node and the target node is in 
a later layer than the source node (because time can only increase). Additionally, background 
knowledge such as the geo-position of the PoSes, etc. can be utilized to further reduce the 
superset of plausible edges and thereby simplify the search problem. 

For privacy, two characteristics are important: How many solutions do exist and what is the 
computational complexity to find one (or all) solutions? This results in a trade-off between 


two borderline cases: 


(1) There is exactly one unique solution. At first glance, this contradicts privacy. However, 


the mere existence of a unique solution is worthless, if it is computationally infeasible to 


find it. 


(2) Finding a solution is easy but there are many equally valid solutions. In this case privacy 


is preserved as well. 


If additional background information is omitted, the problem can be cast as a specialized 
instance of various NP-complete problems, e.g., the parallel-version of the KNAPSACK problem 
or a generalized version of the PARTITION SUM problem with variable partition sizes. For 
general instances, these problems are NP-complete. This is beneficial as it implies that finding a 
solution is generally believed to be intractable. However, there might be good heuristics for all 
"natural" instances. Moreover, depending on the concrete parameters (e.g., an upper bound on 
the maximum price p or the balance bP!) the problem might become fixed-parameter tractable 
[Alb+18]. In other words, although solving the general problem is assumed to have super- 
polynomial runtime in the instance size, it might still be practically solvable for “real world" 
instances. We stress again, that an in-depth analysis requires to look at concrete distributions 
of these parameters which may be the basis for an independent work. 

Nonetheless, there are indicators that—if finding one solution is easy—there might be a 
myriad of solutions, which again yields privacy. In [Nag+20], the authors sketch such estimation 
for the German Toll Collect System which indicates that the solution space for mapping a 
particular user (there: truck) to a specific wallet (there: trip) might be vast. 

In practice, several privacy notions like k-anonymity are established. For several reasons 
these notions are not directly applicable here. First of all, these notions evaluate the privacy 
level of a concrete dataset and we stress again that this is out of the scope of this work. While 
at first glance the calculations above might suggest that our system features k-anonymity 
[Sweo2] for some yet to be determined k, the notion of k-anonymity is actually not applicable 


due to formal reasons. The definition of k-anonymity requires the database to have exactly 
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one entry for each individual, but our transaction database features several entries per user. 
Therefore, the notion of k-anonymity is syntactically not applicable to the users of our system. 
While we could still discuss k-anonymity in this setting if the operator combined all entries 
that pertain to the same user into one single entry, privacy of our system largely stems from 
the operator not being able to link transactions of the same user in this way and hence such a 


discussion would largely undervalue the privacy protection P5C provides. 


5.4 Alternative Approaches 


In this section we would like to discuss alternatives for two aspects of the definition. The 
first section sketches a different approach to model the distributed state of the system and the 
resulting inconsistencies instead of using tags. The second section does actually not present 
a proper alternative, because the approach turns out to be non-working. However, it is still 


presented, because it seems to be a very obvious approach at first glance. 


5.4.1 An Alternative to Tags and the Case of [Nag+20] 


In order to accurately model a distributed system with inconsistent knowledge of the individual 


parties, two nearby solutions exist: 


(1) (The proposed approach) The ideal functionality additionally outputs some administrative 
meta-information—called tags here—alongside the actual output in certain tasks. Later 
these tags are re-input into those tasks that need them. On a conceptional level this 
implies that the ideal functionality assumes the existence of a framing protocol which 


transports information between parties and is played by the environment. 


(2) (Alternative approach) The ideal functionality manages an array of indices (or some other 
kind of reference pointers) to represent which piece of information is known by which 
party. The parties' in-/output only consists of information that have a straightforward 
semantic interpretation in the context ofthe task at hand. The ideal functionality provides 
an explicit Sync operation that allows parties to mutually update their state of knowledge. 
Under the hood, an invocation of Sync let fpc update which piece of information is 


accessible by which party. 


The main advantage of the alternative approach is that it provides a cleaner interface as honest 
parties do not export any internal information to the caller protocol. Also, this definitional 
approach seems to be better decoupled from a particular implementation at first glance. How- 


ever, this first impression fails and it has turned out that getting the definition right under this 
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approach ends up in an incomprehensible clutter of indices. This runs contrary to the idea that 
the ideal functionality should grasp a plausible definition of security. 

We argue that both approaches are mostly equivalent and more a question of style. In both 
cases, a potential implementation would most likely use some sort of tags in the one or other 
way to synchronize the parties’ state from time to time. The main difference is that these tags 
are either (1) transported over the usual communication channel using incoming/outgoing 
message tapes, or (2) transported with the help the environment using input/output. In both 
cases, the environment has the same set of possibilities to maliciously manipulate these tags 
either directly by itself or with the help of the dummy adversary, 

Using the proposed approach, it is rather evident that Jape must not make any assumptions 
about how the framing protocol, i.e. the environment, forwards the tags. For example, there 
is even no guarantee that a tag that is later input into a task has ever been output before by 
another task. Making the tags an explicit part of the ideal functionality enables to formalize 
conditions on non-excludable attacks in more comprehensible way. Hiding away these tags 
under the cover of an indirect indexing scheme leads to more artificial conditions that are not 
easily justifiable. 

The approach taken in [Nag+20] lies somewhere in the middle of both approaches. Tags are 
not part of the ideal functionality, i.e. the in-/output interfaces are very clean, but the ideal 
functionality does not keep track of what is known by which party neither. Instead, the real 
implementation provides tags, but keeps them in the local state of each party and assumes that 
the internal state of one party is “magically” transported to another party by some not explicated 
mechanism of synchronization that is spontaneously executed when favorable. In some sense, 
the protocol in [Nag+20] implicitly re-introduces the assumption of globally available and 
perfectly consistent state. Strictly spoken, it does not realize the proposed ideal functionality 
there. Unfortunately, the problems have not only been a lack of thorough formalism, but as it 
has turned out the protocol in [Nag+20] actually contains some insecurities that have been 


overlooked. These insecurities have been unveiled during the write-up of this thesis and fixed. 


5.4.2 Balance Recalculation 


The task RecalculateBalance is defined as a one-party task which is conducted by the operator 
who exclusively provides the input. If the operator provides faulty input, the calculated 
balance is wrong (cp. Section 4.4.3). In essence, the task RecalculateBalance provides very little 


correctness guarantees. This corresponds to the typical “bogus-in-bogus-out” principle. At 


^ Formally, this is not completely true. Using the alternative approach, the environment might be required to 


formally corrupt one of the communication parties first, before gaining all the options it immediately has under 
the approach used here. But this technicality is irrelevant for the point we want to make. 
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first glance it might seem that this only affects the operator itself but has no security impact on 
other parties. This is true on a technical level within the scope of the security model. However, 
a wrong balance might have an impact in the “real world”, if the result is used to file a claim 
against a user. Hence, a more practical solution should also provide evidence that the result is 
correct or allow the user to appeal against it. 

In [Nag+20] the definition of the ideal task BlacklistUser (including the recalculation part‘) 
provides stronger guarantees than what is actually fulfilled by the implementation in [Nag+20]. 
Again, the root of the problem is that the synchronization of states is not modeled in [Nag+zo]. 
In contrast to other fixes between this thesis and [Nag+20], this problem has been fixed by 
unilaterally weakening fpc and not tackling the implementation. 

We are convinced, that a stronger (and more useful) variant of the task RecalculateBalance 
could be provided, but at the costs of major rework of the implementation. In a nutshell, 
the prove-participation tags and recalculation tags have to be fused into one kind of tag 
and the implementation Deposit/Disburse require an additional round of communication. 
Moreover, RecalculateBalance needs to be converted into an optional’ two-party task between 
the operator and user. The presentation here mostly follows [Nag+20] and the envisioned 


improvements are discussed in Chapter 10. 


5.4.3 The Commitment Problem and the Lack of Modularity 


As stated in Chapter 3 the UC framework does not only provide strong security guarantees 
under concurrent execution in arbitrary environments, but comes with two great promises: 
composition and modularity. However, the definition of fpc in Chapter 4 captures anonymous 
point collection in a monolithic functionality and only makes little use of modularity. Section 1.2 
touches a tempting alternative: define an ideal functionality for each of the tasks, realize each 
of them by a protocol, analyze their security separately and deduce the security of the system 
using the UC composition theorem. If this was possible, this would make the proofs much 
easier and give higher confidence that they are correct. 

This raises the question why such a modular approach has not been used. Chapter 4 argues 
that a monolithic definition allows to define the security of anonymous point collection more 
evidently, because a global database that keeps track of all transactions conveys a direct 
semantic interpretation and avoids a slew of technical subtleties due to the distributed state 
between the individual tasks that would arise otherwise. However, the problem is actually 
more than a skin-deep technicality. The rest of this section does not try to present an alternative 


approach, but argues why this alternative approach turns out to be infeasible. 


* In [Nag+20] BlacklistUser combines the tasks Blacklist Wallet and RecalculateBalance. 


7 The participation of the user must be optional in order to cover those cases in which the user refuses to participate. 
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Although UC promises modular proofs, complex protocols which have been proposed with 
a UC-proof rarely use this feature. Instead they are formalized as monolithic entities and 
proven secure from scratch. fpc is no exception. Other examples are UC-formalizations of 
P-signatures [Cam+15] or commit-and-prove [Lino3]. We encounter the so-called “commitment 


problem" [CDT19] of simulation-based security definitions. 


For the rest of the discussion, we need push forward some of the cryptographic building 
blocks, namely commitments as well as ZK-proofs (cp. Section 6.2), and how they are used in 
the realization (cp. Chapter 7). Readers who are completely unfamiliar with these building 


blocks should skip the rest of this section on a first reading. 


A typical structure found in many complex protocols is a commit-and-prove construction, 
which is also widely used in our proposed realization. A party commits to a secret message 
m and proves in zero-knowledge that the message hidden inside the commitment c fulfills 
some predicate P. In other words, the receiver of the commitment is not only asserted that the 
sender is bound to a value, but that this value fulfills certain constraints given by P. Although 
abstract UC-functionalities Fom and Fzg for commitments and zero-knowledge proofs, resp., 
exist [e.g., cp. Canos], these functionalities cannot be used to modularly construct a UC- 
functionality % which in turn captures commit-and-prove. The underlying reason is that the 
actual primitives, i.e. real commitments and real ZK-proofs, offer interfaces which do not exist 
in the ideal functionalities. This allows to assemble these primitives in the real model in a way 
that cannot be achieved in the ideal model. For the scenario at hand, e.g., the commit-and-prove 


construction, the problem is also illustrated in Fig. 5.1. 


The ideal functionality Fzk for zero-knowledge proofs is parameterized by a statement- 
witness relation Ry, = (stmnt, wit). When the prover inputs a tuple (stmnt, wit), Fzg checks 
if Rg, is fulfilled and only outputs the decision bit to the verifier. For the commit-and-prove 
construction, the concrete ZK-relation is Rgp := Ke, (m, d)) | P(m) ^ Open(m, c,d) = 1] with the 
commitment c — stmnt as the statement and the secret message together with the opening 


information (m, d) — wit as the witness. 


The ideal functionality Ko, for a commitment receives the message m from the committer, 
stores m internally and only outputs a notification bit to the receiver. Later, when the committer 
decides to unveil the message, Fom forwards m to the receiver. Please note, that the receiver 
does not learn anything beyond a single bit in the commitment phase. Especially, there is no 
commitment message c. Fom is information-theoretically secure. There is no decommitment d 


neither, not even at the committer's side. 


But this is exactly the point, where the step-by-step transition from the real to the ideal 


model fails. Fzg expects c and d as part of its input, which are output by the real commitment 
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scheme, but not by its ideal counterpart’ Interestingly, the (completely) real construction is a 
UC-secure realization of %,’ nonetheless, but this can only be proven in a monolithic way not 
by composition. 

Figure 5.1 shows a commuting diagram which illustrates the favored, but failing construction. 
The upper left corner represents a completely real protocol consisting of a real commitment 
scheme Teom, a real ZK-scheme 77, and a base protocol zp. The base protocol receives 
a message m from the environment, input m into Teom, receives a decommitment d, feeds 
this into zzy and finally outputs what zzy outputs. Please note, that the construction only 
works, because the base protocol exploits com: The base protocol access om in a whitebox- 
fashion and directly utilizes the commit message and decommitment information c, d from 
the underlying commitment primitive, although c,d is not part of the prescribed output of 
Rom (illustrated by the curly line). The lower left corner represents the ideal functionality 
Fop- Going down from upper left to lower left is possible and represents the monolithic proof. 
However, the preferred, modular proof would first go the upper right. The upper right corner 
represents a hybrid in which zzy has been replaced by F7x. This step is (syntactically) possible 
and the proof (using suitable building blocks) also holds. However, replacing tegom by Rom is 
impossible, as the decommitment d is lost. Le., the construction in the lower right corner does 


not even exist. 


At first glance, the problem arises from the fact that om provides information-theoretic 
security, while a UC-secure real commitment only provides computational security.‘ Having 
in mind, that the completely real construction is indeed UC-secure, one might conjecture that 
the ideal formalizations of the building blocks are overly strong beyond what is required for 
security. To address this problem, a number of approaches have been proposed—none of them, 
however, being able to fully satisfactorily formalize the weaker guarantees achieved by regular 
schemes. First, the notion of non-information oracles [CKo2] has been proposed that essentially 
embeds a game-based definition in a composable abstraction module. Unfortunately, it remains 
unclear what “kind” of security this new notion implies. In essence, a non-information oracle 
provides the missing piece of information. But there is no sound justification why the facilitated 


construction remains secure, especially why it does not fail under arbitrary composition. 


* Note that we are deliberately lying at this point. Of course, the real UC-commitment scheme 7,,,,, must not 


output the decommitment d to the committer, because otherwise it would not even syntactically realize Fom due 
to a different IO interface. The crucial point is that the commit-and-prove construction uses the game-based 
notion of a commitment scheme or makes white box access into Teom- 

Again, we are deliberately lying. Of course, there is no automatism that all combinations of a real commitment 
scheme and a real ZK-protocol which are composed this way, yield a UC-secure commit-and-prove scheme. The 
commitment scheme and the ZK-protocol still needs to be carefully chosen. 

This is so, as a UC-commitment needs to be extractable. 


9 
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stmnt :=c 
| wit = (m, d) 


G) j 6) oK © (4) stmnt, = 
E 


" Lf ) 
cp < : 


Construction does not exist! 


Figure 5.1: The commitment problem in case of commit-and-prove 
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Only very recently, Camenisch, Drijvers, and Tackmann [CDT19] have captured this lack of 
modular proofs as a generic problem and proposed a new framework called multi-protocol UC. 
The essential trick is not to consider a single challenge protocol eom or zzy and replace them 
step-by-step, but consider a set of challenge protocols (meom: zg) and replace them en bloc. 
The obvious drawback is that one must still separately prove that (om; zzk) jointly realize 
(Kom; f zy). Hence, the approach is not completely modular but still somewhat modular. More- 
over, it is not completely clear, whether the construction is flawed. For the proof Camenisch, 
Drijvers, and Tackmann [CDT19] assume the verifier to be incorruptible which is a very strong 
and unrealistic assumption. They only argue that this condition can be dropped. 

On top, our proposed construction requires a feature which has not been addressed so far. 


We require homomorphic commitments. This make the problem of modularity even worse. 
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In this chapter we introduce the algebraic setting and building blocks we make use of. In 
particular, the latter includes non-interactive zero-knowledge proofs, commitments, signatures, 
encryption and pseudo-random functions. Due to efficiency reasons our building blocks are 
not completely generic and do not work over sets of arbitrary (unstructured) bit strings, but 
are algebraic and share particularly related groups as their common definitional space. In 
Section 6.1 we describe this common framework. In Section 6.2 we define the building blocks, 
describe possible instantiations for these building blocks and explain how these primitives are 


used in our system. 


631 Algebraic Setting and Hardness Assumptions 
The following definitions are adopted from [Nag+17]. 
Definition 6.1 (Pairing) 


(1) Let Gi = (gi), Go = (g2), Gr = (gr) be three cyclic groups of prime order p and gi, £9, gy, 
resp., their generators. A map e : G( x Gp — Gy with 


Va € Gi, b € Go, x, y € Zy : e(a*, bY) = e(a, py? (6.1) 
is called bilinear or a pairing. 


(2) A pairing e is called non-degenerated if and only if e(g1, g2) generates Gr. 


Please note, that the co-domain of a pairing e is a sub-group of Gr. Hence, for prime order 
groups, e is either trivial, i.e. e(a, b) = 1 Va € G,,b € G, or non-degenerated, i.e. generates the 
whole target group. 

Moreover, e is called efficiently computable, if there is an efficient algorithm that evaluates 
e on its inputs. In cryptography, we are only interested in "useful" pairings that are non- 
degenerated and efficient. From here and below the term “pairing” always implicitly denotes 


this particular kind of pairing. 
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Definition 6.2 (Prime-order Bilinear Group Generator) A prime-order bilinear group 
generator is a PPT algorithm Setup that on input of a security parameter 1” outputs a tuple of 
the form 


gp = (Gy, Go, Gr, €, P, £1, 82) = Setup(1") (6.2) 


with G1, G2, Gr being descriptions of cyclic groups of prime order p, logp = O(n), gı being a 
generator of G4, g being a generator of Gy, and e : G, x Ga > Gr being a (non-degenerated, 
efficient) pairing. W.l.o.g we assume gy = e(g1, 22). We call gp a (prime-order) bilinear group 


description. 


A bilinear group description can be typed according to how the involved groups relate to 


each other with respect to computational complexity. 


Definition 6.3 (Types of Bilinear Group Setting) Let gp := (G1, G2, Gr, e, p, 81,82) be a 


bilinear group description as above. 


Type 1: gp is said to be of Type 1, if and only if an efficiently computable isomorphism between 


G, and G, exists. Type 1 is also called the symmetric case. 


Type 2: gp is said to be of Type 2, if and only if an efficiently computable homomorphism 
V : G > G exists, but the inverse | : G, > G is computationally hard. 


Type 3: gp is said to be of Type 3, if and only if there is no efficiently computable homomorphism 


between G, and G, neither way. Type 3 is also called the asymmetric case. 


In the remainder of this thesis, we only consider the asymmetric setting. 
Most of our building blocks make use of a particular projection F,, : Z$ x Gf x Zpx Gy > 
Gj x G5 with x denoting an arbitrary number of components. For lack of a better name we 


simply call it the F,,-mapping. 


Definition 6.4 (F,p-mapping) Let G, = (gı) and Gy = (g») as before. For a, f, y,Ó € N let 
the famil tions [Fo P9) be defined 
e family of func ions | ‘ep jos e defined as 


Zt x GP x Zi x Gio Gitte x art? 
WA 
Fehr ) R (n,, ... Ma Bits. hip m;,...,my, hj; «ho 5) b (6.3) 


n n, m. m 
(m. ine hog, 82 PER >, 83 E hoy. shy 5) 


Informally, FIO maps Z,„-elements to G; and Go, resp., by exponentiation and acts on G; and 
G» as the identity function. 
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Then, F,, is defined as the “union” over this family, or more precisely Fyp(x) = ESTO y) for 
x € Z8 x Gf x ZY x G). 


Beware, that Ee and po M are syntactically indistinguishable for a+ y = a^ + y” 
and f = 0, but in the following the correct domain is always clear from the context. F,, is 
indeed a projection as Fy, ° Fy) = Fgp (for matching choices of dimensions). Moreover, if the 
domain is fixed (i.e. for given a, P, y, ô), then Fop is injective and thus invertible’ on the restricted 
domain. (This is important in the later definition of proof of knowledge.) 

We are now ready to present the hardness assumptions which the instantiations of our 
building block rely upon. This concludes this section. 


The co-CDH assumption is defined as follows 


Definition 6.5 (Co-CDH Assumption) Let gp := (G4, Go, Gr, e, p, £1, £2) — Setup(1”). We 
CO-CDH 


say that the co-CDH assumption holds with respect to gp, if the advantage Adva — (1") 
defined by 


x 2 Zy | (6.4) 


Pr | = 8 
a «- AC", gp, gr) 


is negligible inn for all PPT algorithms A. 


The SXDH assumption essentially asserts that the DDH assumption holds in both source 
groups G; and G, and is formally defined as: 


Definition 6.6 (SXDH Assumption) Let gp := (Gy, Gy, Gr, €, p, 81, 22) — Setup(1”). 


(1) We say that the DDH assumption holds with respect to gp over G; if the advantage 


Advepna(1”) defined by 


xyz Zp; ho = gh = g7 
1 
Pr|b =b b È {0,1} E (6.5) 
b’ — AC”, gp, 87, g?, hy) 


is negligible in n for all PPT algorithms A. 


(2) We say that the SXDH assumption holds with respect to gp, if the above holds for both 
i=1landi=2. 


* N.b., we do not require F,, to be efficiently invertible. 


109 


6 Assumptions and Building Blocks 


The n’-DDHI assumption (Decisional Diffie-Hellman Inversion assumption) states that no 
efficient adversary can distinguish g /* from a random group element after having seen n’ 


consecutive group elements for increasing powers of x. 


Definition 6.7 (n’-DDHI Assumption) Let G, be a prime-order group with p € O(2") and 
generator g1. We say that the n’-DDHI assumption holds with respect to G, if the advantage 
Adve 41") defined by 


x& Zp; hg = gl/* hy = e 


ren 


Pr|b - bl b È (0,1) == (6.6) 
b (1G, (ni gf arsi hp) 
is negligible inn for all PPT algorithms A. 
The co-DLIN assumption is defined as follows: 


Definition 6.8 (co-DLIN Assumption) Let gp := (G,,G»,Gr,e, p, 81,82) — Setup(1"). We 


say that the co-DLIN assumption holds with respect to gp, if the advantage Advi ay N(17) 


defined by 
a, py 2 Zp 
b È {0,1} 
Pr|b-b' hy = gg, hy: gj. ha: q. (6.7) 
t B+by 


hy ; RAD : Bohs Í E 
b’ — AQ", gp, hy, ha, ha, hi, hz, ha) 


is negligible inn for all PPT algorithms A. 


Our construction relies on the co-CDH assumption and the security of our building blocks 
(cp. Section 6.2). For our special instantiation of the building blocks, security holds under the 


SXDH and co-DLIN assumption. The former implies the co-CDH assumption. 


6.2 Cryptographic Building Blocks 


Our semi-generic construction makes use of various cryptographic primitives including (F,,- 
extractable) NIZK proofs, equivocal and extractable homomorphic commitments, digital signa- 
tures, public-key encryption, symmetric encryption and pseudo-random functions. All building 
blocks are aligned to a bilinear group setting in the type 3 case, i.e. they do not require an 


efficiently computable homomorphism between the involved groups. On the contrary, the 
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security of their instantiation relies on the fact that such an homomorphism does not exist. 
In the following, gp := (G4, Go, Gr, €, p, £1, 82) * Setup(1") denotes a suitable bilinear group 
description (cp. Definition 6.2). 

Additionally, the latter building blocks need to be efficiently and securely combinable with 
the chosen NIZK proof system, which is Groth-Sahai (GS) in our case. In the following, we 


formally define these building blocks and describe possible instantiations. 


6.2.1 Non-Interactive Zero-Knowledge Proofs 


Let Rgp be a witness relation for some NP language 


Li [stmnt | 3 wit s.t. (stmnt, wit) € Rgp}. (6.8) 


Sp 


A zero-knowledge proof allows a prover P to convince a verifier V that some stmnt is contained 

in Lg, without V learning anything beyond that fact. In a non-interactive zero-knowledge 

proof (NIZK), only one message, namely the proof z, is sent from f? to V for that purpose. 
More precisely, a (group-based) NIZK scheme is defined as: 


Definition 6.9 (Non-Interactive Zero-Knowledge Proof Scheme) Let gp := (G4, Go, Gr, 
e, p. 81, 82) <— Setup(1") be as usual and F,, the projection as in Definition 6.4. Let Rgp be an 
efficiently verifiable relation containing tuples (stmnt, wit). We call stmnt the statement, and wit 
the witness. Let Ly, be the language containing all statements stmnt such that (stmnt, wit) € Rgp. 
Let POK := (Setup, Prove, Vfy) be a tuple of PPT algorithms such that 


* Setup takes as input gp and outputs a (public) CRS crspo\. 


* Prove takes as input the CRS crs a statement stmnt, and a witness wit with (stmnt, 


pok: 
wit) € Rop and outputs a proof n. 


e Vfy takes as input the CRS crs „og, a statement stmnt, and a proof x and outputs 1 or 0. 


pok? 
POK is called a NIZK proof scheme for Rgp with F,„-extractability, if the following properties are 
satisfied: 


(1) Perfect completeness: For all crspok + Setup(gp), (stmnt, wit) € Rgy, and x. — 


Prove(crs og, stmnt, wit) we have that Vfy(ers og, stmnt, 1) = 1. 


pole pok> 


(2) Perfect soundness: For all (possibly unbounded) adversaries A we have that 


CTS nok + Setup(gp) 
Pr | 0 <- Vfy(ers,og, stmnt, 1) | (stmnt, 1) — Alerspok) (6.9) 


stmnt € Lep 
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is 1. 


(3) Perfect F,,-extractability: There exists a polynomial-time extractor (SetupExt, Extract) 
such that for all (possibly unbounded) adversaries A 


(a) we have that the advantage Adv oea P (gp) defined by 


IPr[1 < Alersyox) | CTSpok € Setup(gp)] 


E Pr[1 — ACerS ok) | (ers ok: td nok) e SetupExt(gp)]| (6.10) 


is zero. 


pok-ext 


pok, EP) of a successful extraction defined by 


(b) we have that the probability Succs 


(erst ok? tdepok) — SetupExt(gp) 


: 3 wit : Fo (wit) = Wit ^ (stmnt, 1) — AC Crs. ok: tdepok) Gas 
r al 
(stmnt, wit) € Rep 1<- Vf (erst ok: stmnt, 77) 
Wit — Extract(crs’ oo tdepok; stmnt, 77) 
is 1. 


(4) Composable zero-knowledge: There exists a polynomial-time simulator (SetupSim, 
ProveSim) such that for all PPT adversaries A 


(a) we have that the advantage Advb oiea "P PI (gp) defined by 


IPr[1 - Alersyox) | CTS poke + Setup(gp)] 


B Pr[1 = ACerS ok) | (ers ok? td pok) e SetupSim(gp)] | (6.12) 


is negligible in n? 


2 N.b., the terms implicitly depend on n, because gp + Setup(1") does and we require log p € O(1") for the group 
modulus 
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(b) we have that the advantage Advb a (gp) defined by 


ProveSim(crs\ og; td sos) 


[Pr[1 <A (erste tdspok)| (ers ote tdenok) — SetupExt(gp)] 


Prove(crs’ |.) 
Velers oi Cers oe td yg) | (Crs ote tdepok) “e SetupExt(gp)]| 


(6.13) 


-Pfie A 


is negligible in n. Here, A has oracle access either to ProveSim(crs’ |, td. -) or 


pok> 
Prove(ers, oo -,*). Both ProveSim and Prove return L on input (stmnt, wit) € Rep: 


spok? `> 


We wish to point out some remarks. 
Remark 6.10 


(1) Fgp-extractability actually implies soundness: If there was a false statement stmnt which 
verifies and thus violates soundness, then there is obviously no witness wit for stmnt, which 


violates extractability. 


(2) Extractability essentially means that Extract—given a trapdoor td is able to extract 


epok - 
Fgp(wit) for an NP-witness wit for stmnt € Lgp from any valid proof n. If Fs, is the identity 


function, then the actual witness is extracted and the scheme is called a proof of knowledge. 


Our Instantiation 


We choose the SXDH-based Groth-Sahai (GS) proof system [EG14; GSo8] as our NIZK scheme. 
On the one hand, it allows for very efficient proofs under standard assumptions. On the other 


hand, GS comes with two drawbacks which makes using it sometimes pretty tricky: 


« Extract only extracts an F,,-mapping F,,( wit) of the witness and thus GS is not a real 


proof of knowledge, if the witness contains Z,-elements. 


e GS does not support arbitrary relations Ry, over the underlying groups but only systems 


of certain restricted types of equations. 


We work around both issues by carefully choosing the remaining building blocks and the 
languages of NP-statements we need to prove. Also, in many places, the proof of security 
for our system does not require This holds indeed, if the co-domain of F,, is restricted to the 
particular NP-language under consideration. a true proof of knowledge. The existence of a 
unique witness suffices. This holds indeed, if the co-domain of F,, is restricted to the particular 
NP-language under consideration. 

For the sake of completeness, we summarize what types of equations are supported by GS. In 


the following, let X], X2, ... € Gy, x1, X2, ... € Zp» Y1, Y2, ... € G2, as well as y, y2, ... € Zy denote 
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secret variables, i.e. the witnesses, and let A, Aj, A5,... € Gy, 41,42,... € Zp, B, By, Bg, ... € Ga, 
b1, bz, ... € Zp, C € Gr as well as c, c1 1,C1,2,C2,1,-.- Zp denote public constants. 


e Pairing-Product Equation (PPE): 


Gj 
II«^vo[Ie05.5) I] Ie Y)" =¢ (624) 
i j ij 

if there is a known decomposition for C = Il;e(A;; Bi) with public constants A1, A^, ... 
€ G and Bi, B2,... € G». 


e Multi-Scalar Equation (MSE) over G;: 
ILeTISTITIS^ =4 (ox) 
i j Pj 
e Multi-Scalar Equation (MSE) over Gs: 


TIS TIS TITIS^ = (626 
J t J 


i 
* Quadratic Equation (QE) over Zy: 


> ax + y biy¡+ y y Gy =c (6.17) 
j i j 


i 


6.2.2 Commitments 


A commitment scheme is a two-party protocol between a sender and a receiver. In the first 
phase—called the commit phase—the sender commits itself to a message m such that the message 
remains hidden to the receiver. Later, in the second phase—called the unveil phase—the sender 
unveils the message to the receiver and the receiver is convinced that the sender has been 
bound to the original message and is unable to claim a different message. A commitment 
scheme is called non-interactive, if committing and unveiling only requires a single message 
from the sender to the receiver. Let gp := (G4, G2, Gr, e, P, 81,82) * Setup(1”) be as usual 
and F,, the projection as in Definition 6.4. A commitment scheme is called an (group-based) 
commitment scheme with F,,-binding, if the sender commits to a message m but unveils the 


commitment using F,,(m). We call the codomain of F,, the implicit message space. 


Definition 6.11 ((Group-Based, Non-Interactive) Commitment Scheme) 
A (group-based) commitment scheme COM := (Setup, Commit, Open) with F,,-binding consists 
of three algorithms: 
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e Setup is a PPT algorithm, which takes gp as input and outputs public parameters crscom. 


e Commit is a PPT algorithm, which takes as input parameters crscom and a message m € M 


and outputs a commitment c to m and some decommitment value d. 


e Open is a deterministic polynomial-time algorithm, which takes as input parameters crscom; 
a commitment c, an implicit message M € M', and a decommitment value d. It returns 


either 0 or 1. 


COM is correct if Open(crscom, Fgp(m), c, d) = 1 holds for all crScom © Setup(gp), m € M, and 
(c, d) = Commit(ers.om; m). 

We say that COM is hiding, F,,-binding, equivocal and extractable, if it the following 
properties hold: 


(1) Hiding: For all PPT adversaries A it holds that the advantage Adv OSA (ED) defined by 


CrScom — Setup(gp) 
(mp, mı, state) — AC crscom) 
1 
Pr|b-b b ze 10, 13 x. (6.18) 


(m, d) = Commit(crscom, mp) 


b’ — A(c, state) 
is negligible inn. The scheme is called statistically hiding if Adv OM (gp) is negligible 


even for an unbounded adversary A. 


(2) Fap-binding: For all PPT adversaries A it holds that the advantage Adv Pinding. ep) 
defined by 


Open(crscom, M, c,d) 21^ i5 
crs < Setu 
Pr | Open(crscom,M’,c,d’) 2 1^ Dd Ad (6.19) 
(c, M,d, M', d^) — A(1", crscom) 
M+M’ 


is negligible in n. 


(3) Equivocal: There exist PPT algorithms SetupSim, CommitSim and Equivoke such that for 
all PPT adversaries A 


115 


6 Assumptions and Building Blocks 


(a) we have that the advantage Adon oa (SP) defined by 


IPr[1 — Alcrscom) | CrScom — Setup(gp)| 


=Pr|1:= Alersign) | (crstom> fdeqcom) — SetupSim(gp)] | (6.20) 


is negligible in n. 


(b) we have that the advantage Adv a (EP) defined by 


T (erscom» tdeqcom) < SetupSim(gp), 
Pr 1 "e A com> eqcom» Wie M, 
m,c,d 
(c,d) — Commit(crstom, M) 
(crstom: tdeqcom) < SetupSim(gp), 
CTS. on, td 3 (c’,r) = CommitSim(gp), 
E Pr 1 a A com eqcom &P (6.21) 
m,c',d' m — M, 
d’ <— Equivoke(crstom, tdeqcom, m, r) 
is zero. 


(4) Fgp-Extractable: There exist PPT algorithms SetupExt and Extract such that for all PPT 


adversaries A 


(a) we have that the advantage AdveON at (gp) defined by 


Pr[1 — Alcrscom) | C'$ com < Setup(gp)| 


B Pr[1 «- Alcrscom) | (erscom; tdextcom) — SetupExt(gp)]| (6.22) 
is negligible in n. 
(b) we have that the advantage Adveom.a(n) defined by 


" 3m,r: c= Commit(crstom,m3r) A | (crstom; tdextcom) * SetupExt(gp), 
r 


Extract(crscom; tdextcom: €) + Fo (m) c «— Alcrslom) 


(6.23) 
is zero. 


Furthermore, assume that the message space of COM is an additive group. Then COM is called 
additively homomorphic, if there exist additional PPT algorithms c + AddC(crscom, C1,C2) and 
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d — AddD(crscom, di, da) which on input of two commitments and corresponding decommitment 
values (c1, d4) = Commit(crscom, m4) and (cz, dz) <— Commit(crscom, M2), output a commitment 
c and decommitment d, respectively, such that Open(crscom, €, F, (m, + m2), d) = 1. 

Finally, we call COM opening complete if for all M € M' and arbitrary values c, d with 
Open(crscom;M,c,d) = 1 holds that there exists m € M and randomness r such that (c, d) — 


Commit(CrScom» m; r). 


Our Instantiation 


We will make use of two commitment schemes that are both based on the SXDH assump- 

tion. We first use the shrinking a-message-commitment scheme from Abe et al. [Abe+15]. 

This commitment scheme has message space ZZ, commitment space G, and opening value 

space G4. It is statistically hiding, additively homomorphic, equivocal, and F;,-Binding, for 
(D 


Fé (m, ..., Ma) = in u) We use this commitment scheme as C1 with CRS crscóm and 


C2 with CRS erst in the following ways in our system: 
* In IssueWallet and ProveParticipation we use C2 for messages from Zy. 
e In IssueWallet we use C1 for messages from Zo, Zi and Zi. 
« In Deposit task we use C1 for messages from Z, and Z$. 


We also use the (dual-mode) equivocal and extractable commitment scheme from Groth 
and Sahai [GSo8]. This commitment scheme has message space G4, commitment space G? and 
opening value space zs It is equivocal, extractable, hiding and Fz;-Binding for Fzj(m) := m. 

(4) 


In our system, we use this commitment scheme as C4 with CRS crscom in IssueWallet and 


Deposit. 


6.2.3 Digital Signatures 


A signature allows a signer to issue a signature c on a message m using its secret signing key 
sk such that anybody can publicly verify that o is a valid signature for m using the public 
verification key pk of the signer but nobody can feasibly forge a signature without knowing sk. 
Again, we only consider a group-based setting. The standard definition of signature scheme 
security, EUF-CMA, has been introduced by Goldwasser, Micali, and Rivest [GMR88]. 


Definition 6.12 ((Group-Based) Signature Scheme) A digital signature scheme SIG := 
(Gen, Sign, Vfy) consists of three PPT algorithms: 


e Gen takes gp as input and outputs a key pair (pk, sk). The public key and gp define a 


message space M. 
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* Sign takes as input the secret key sk and a message m € M, and outputs a signature c. 


* Vfy takes as input the public key pk, a message m € M, and a purported signature c, and 


deterministically outputs a bit. 


We call SIG correct if for all m € M, (pk,sk) — Gen(gp), o — Sign(sk,m) we have 1 — 
Vfy(pk, c, m). 

We say that SIG is EUF-CMA secure if for all PPT adversaries A it holds that the advantage 
Advie a ^ (19) defined by 


gp — Setup(1”) 
k,sk G 
Pr | Vfy(pk,o*,m*) =1 Des an en (ap) (6.24) 
(m*,o*) — ASignisk,)(1n, pk) 


m* € {mı,...,mg} 


is negligible in n, where Sign(sk,-) is an oracle that, on input m, returns Sign(sk,m), and (m,,..., 


mq} denotes the set of messages queried by A to its oracle. 


Our Instantiation 


As we need to prove statements about signatures, the signature scheme has to be algebraic. For 
our construction, we use the structure-preserving signature scheme of Abe et al. [Abe+11], which 
is currently the most efficient structure-preserving signature scheme. Its EUF-CMA security 
proof is in the generic group model, a restriction we consider reasonable with respect to our 
goal of constructing a highly efficient BBA* scheme. An alternative secure in the plain model 
would be [KPW15]. For the scheme in [Abe+11], one needs to fix two additional parameters 
Ji, v € No defining the actual message space GY x G}. Then sk € ge pke Gite x G} and 
c €G2x Gy. 

We use the signature scheme SIG from Abe et al. [Abe+11] in the following ways in our 


system: 


* For messages from G,xGl (v = jand p = 1) to sign the fixed part of a wallet in IssueWallet. 


e For messages from G, x G, (v = 1 and u = 1) to sign the updatable part of a wallet in 
IssueWallet and Deposit. 


« For messages from G? (v = 3 and y = 0) to sign recalculation tags in IssueWallet and 


Deposit. 


- For messages from (G x G3) x (G2 x G3) x G? (v = 5 + y and y = 4) to sign the public key 
and the attributes of a PoS in the CertifyPOS and RegisterOp. 
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6.2.4 Asymmetric Encryption 


We use the standard definitions for asymmetric encryption schemes and corresponding secu- 
rity notions, except that the algorithms take gp := (G1, Go, Gp, e, p, 81, 22) * Setup(1") as an 


additional parameter to fit our algebraic setting. 


Definition 6.13 (Asymmetric Encryption) An asymmetric encryption scheme ENC := 
(Gen, Enc, Dec) consists of three PPT algorithms: 


* Gen(gp) outputs a pair (pk, sk) of keys, with pk being the (public) encryption key and sk 
being the (secret) decryption key. 


* Enc(pk, m) takes a key pk and a plaintext message m € M and outputs a ciphertext c. 


* Dec(sk,c) takes a key sk and a ciphertext c and outputs a plaintext message m or 1. We 


assume that Dec is deterministic. 


Correctness is defined in the usual sense. 
An asymmetric encryption scheme ENC is IND-CCA2-secure if for all PPT adversaries A it 


holds that the advantage Advinca (gp) defined by 


(pk, sk) — Gen(gp) 
(state, mg, m) — APesk)(1, pk) 
Pr] b=b’ b È {0,1} - : (6.25) 
c* — Enc(pk, mp) 


bias APEC Ck) state, c*) 


is negligible in n, with |mo| = |mı|, Dec(sk,-) being an oracle that gets a ciphertext c from the 


adversary and returns Dec(sk,c) and Dec'(sk,-) being the same, except that it returns L on input 


e^. 


An asymmetric encryption scheme ENC is NM-CCA2-secure if for all PPT adversaries A it 
holds that the advantage AdvENG A (1%) defined by 


NM-CCA NM-CCA 
SuccseNC at real (17) = SuccseNC. A random 1^) (6.26) 
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is negligible with 
(pk, sk) — Gen(gp) 
(M, state) — ADectsk,)(1n, pk) 
CECA R 
m-M 
Succes We TECA” ):=Pr| Lema (6.27) 
c — Enc(pk,m) 
R(m,m)=1 , 
(R,c) — ADec (Sk.)(17. state, c) 
m < Dec(sk,c) 
and 
(pk, sk) — Gen(gp) 
(M, state) — ADec(sk,)(1n, pk) 
CECA R 
m,m — M 
Succs M us iandom(1P) = Pr} Lema b (6.28) 
_ c — Enc(pk, m) 
R(m,m) = 1 f 
(R, c) — APecCsk:)(1n, state, c) 
m < Dec(sk, c) 


where M denotes a space of valid, equally long messages, R C Mx M* denotes an relation, Dec(sk, -) 
is an oracle that gets a ciphertext c from the adversary and returns Dec(sk, c) and Dec'(sk,-) is 
the same, except that it returns L on input c. 

An encryption is IND-CCAz secure if and only if it is NM-CCAz secure [Bel+98]. 
Our Instantiation 


We will make use of two different IND-CCAz-secure encryption schemes: 


e We use a variant of Camenisch et al. [Cam+11] to directly instantiate the explicit encryp- 
tion scheme ENCI for the deposit wallet IDs. 


e We use the encryption scheme by Cash, Kilt, and Shoup [CKS08] as the outer encryption 
of ENC2 for the encryption of the recalculation tags. 


e We also implicitly use the same encryption [CKSo8] to realize the secure channels of 


Fmsg Which underlies our model. 


The scheme by Cash, Kilt, and Shoup [CKS08] is based on the twin-DH assumption. For 


efficiency reasons we utilize the typical hybrid approach and use the asymmetric scheme to 
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setup a session key for a symmetric encryption of messages following the KEM/DEM pattern 
(cp. Section 6.2.5). Note that we don’t require any algebraic properties, especially we don’t need 
to prove anything about ciphertexts. For the ease of presentation, we act as if the message space 
of ENC2 was G, x G x Zp x (G? x G3) x (G2 x G1), because this is the space of the recalculation 
tags Wy. However, the encryption scheme Cash, Kilt, and Shoup [CKS08] does not depend on 
this, but treats plain messages and ciphertexts as opaque bit strings. 

The scheme for ENC1 is an adapted variant of the structure-preserving, IND-CCA2 secure 
encryption scheme by Camenisch et al. [Cam-11]. Thus, some remarks are in order. The original 
scheme is formalized for a group setting of type 1, but we need a scheme that is secure in the 
asymmetric type 3 setting. For the conversion we followed the generic transformation proposed 
by Abe et al. [Abe+14] with some additional, manual optimizations. The transformed scheme 
encrypts vectors of G;-elements and is secure under the co-DLIN assumption (cp. Definition 6.8) 
which holds in the generic group model. This follows automatically from [Abe+14] (or can also 
be easily seen by inspecting the original proof in [Cam+11]). We present the modified scheme 
in full detail. 


Definition 6.14 (Type 3 Variant of Camenisch et al. [Cam+11]) Let gp := (G4, Go, Gy, e, p, 
£1. 82) <— Setup(1”) be as usual. Let go be the dimension of the message space BP. The algorithms 
Gen, Enc and Dec are depicted in Figs. 6.1 to 6.3. 


We instantiate this scheme with p = £ + 2. 


6.2:5 Symmetric Encryption 


We use standard definitions for symmetric encryption schemes and corresponding security 


notions. 


Definition 6.15 (Symmetric Encryption) A symmetric encryption scheme ENC := (Gen, 
Enc, Dec) consists of three PPT algorithms: 


* Gen(1") outputs a key sk. 
* Enc(sk,m) takes a key sk and a plaintext message m € M and outputs a ciphertext c. 


* Dec(sk,c) takes a key sk and a ciphertext c and outputs a plaintext message m or 1. We 


assume that Dec is deterministic. 


As for asymmetric encryption, we require correctness in the usual sense. 
We now define a multi-message version of IND-CCAz security. It is a well-known fact that 
IND-CCAz security in the multi-message setting is equivalent to standard IND-CCAz security. 


(This can be shown via a standard hybrid argument.) 
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Gen(gp, $0) 


parse (G,, Gz, Gr, €, P, £1 82) = gp 


R 

Q5, +=» > Qt, Bos ie Bis Ys Yo — Z 

sk := (2 {Biico,...39 disse) 
R 

En... ¿E em Z; 


h, = gi. h, = gj. hs = gj 


Xa heh, Xa hh, fori-1,...,fo 
ya fe pbs, Vio = hehhe, fori = 0,...,3 
Z= hi pis, LL hi? pes, fori=1,...,9 


pk = (hy, ha, hs, hy, hy, m 


La bit. Dis Vi2hizo,..33 Uns Zhi.) 


return (pk, sk) 


Figure 6.1: The key generation algorithm Gen of the adapted CCA-secure encryption scheme 
by Camenisch et al. [Cam+11] with parameter (o and message space GP 


Enc(pk, m) 


parse (hy, hy hs, h, ha, hs, {Xi Xale 
Dio Vi2hio,...39 Us Zahire) = pk 


R 
r,s = Z, 
U, = hi Uy = hs [A = hys 
ty = hi Uy = hj Us = hy 


— r S i- 
G = mix; fori = 1,..., o 
3 


p 
v= | | e (ti, y!,J%2) ] ] 412%) with ù := gi 
i=1 


i=0 
c := (u, c, v) with u :— (4, 15, 43, ú,, 0, 5) and c := (e, ... Cy) 


return (c) 


Figure 6.2: The encryption algorithm Enc of the adapted CCA-secure encryption scheme by 
Camenisch et al. [Cam+11] with parameter (o and message space GP 
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Dec(sk, c) 


parse (faf... o» {Bibizo....3» Witi=1....p) = SK 
parse (u, c, v) := c, (ti, tly, tts, 41, Uz, Us) = u and (c,...,¢,) :=C 
Uy = 81 

3 e 
ifvz II e (à. ur du" II e(o, a d di^) abort 
i=0 


i=1 
if e(ü,g,) #e(g,,u;) for any i € {1, 2, 3} abort 
m; = Git, ^ i, ü, for i € {1,..., e} 

m := (m,,...,mg) 


return (m) 


Figure 6.3: The decryption algorithm Dec of the adapted CCA-secure encryption scheme by 
Camenisch et al. [Cam+11] with parameter (o and message space GP 


Definition 6.16 (IND-CCA2-Security for Symmetric Encryption) A symmetric encryp- 
tion scheme ENC is IND-CCAz-secure if for all PPT adversaries A it holds that the advantage 


Ados ^ (D defined by 


sk — Gen(1") 
(state, j, mo, m4) — AENsk.),Dectsk,)(4™) 
Pr} b - b b — {0,1} == (6.29) 
c* — (Enc(sk, m, 1), ..., Enc(sk, my, ;)) 
b/ — AEne(sk,),Dec’(sk-)(state, c*) 


A 


is negligible in n, where mg, m are two vectors of j € IN bit strings each such that for all 1 € i € j: 
Img ¡| = Imı ‚|, Enc(sk, -) and Dec(sk, -) denote oracles that return Enc(sk, m) and Dec(sk, c) for a 
m or c chosen by the adversary, and Dec'(sk, -) is the same as Dec(sk,-), except that it returns L 


on input of any cf that is contained in c*. 


Our Instantiation 


We use an IND-CCA2-secure symmetric encryption scheme in our protocol to encrypt the 
exchanged protocol messages. To this end, we combine an IND-CCA2-secure asymmetric 
encryption (see Section 6.2.4) with an IND-CCA2-secure symmetric encryption in the usual 
KEM/DEM approach. The symmetric encryption can for example be instantiated with AES 
in CBC mode together with HMAC based on the SHA-256 hash function. The result will be 
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IND-CCAz-secure if AES is a pseudo-random permutation and the SHA-256 compression 
function is a PRF when the data input is seen as the key [Bel15]. 


6.2.6 Pseudo-Random Functions 


A pseudo-random function (PRF)—more precisely a family of PRF's indexed in the seed A—is 
a function F : £x X > Y,(A,x) > y that for a randomly chosen, but constant seed A is 
computationally indistinguishable from a randomly chosen function R : X — Y. In other 
words, any PPT adversary given oracle access to either F(A, -) or R(-) cannot distinguish between 


them with non-negligible probability. Formally, a PRF is defined as follows. 


Definition 6.17 ((Group-Based) Pseudo-Random Function) Let gp := (G4, Go, Gr, €, p, £1; 
g2) — Setup(1”) be as usual. The key space £, the domain X and the co-domain Y may all depend 
on gp. A (group-based) pseudo-random function (PRF) PRF := (Gen, Eval) consists of two PPT 


algorithms: 
* Gen takes gp as input and outputs a seed A € L. 


e Eval is a deterministic algorithm which takes as input a seed A € £ and a value x € X, and 


outputs some y € Y. By abuse of notation, we simply write y = PRF(A, x) for short. 


We say that PRF is secure if for all PPT adversaries A it holds that the advantage Adve") 
defined by 


[prfı  APRFA,)(gp) | A <= Gen(gp)| - Pr[1 — ARO (gp) | RÈ {R: X> Y] (6.30) 
is negligible in n. 


Our Instantiation 


As we want to efficiently prove statements about PRF outputs, we use an efficient algebraic 
construction, namely the EN PRF [DYo4]. This function is defined by PRF(A, x) : 


Zi > Gy (Ax) => 7, where A È Z, is the random PRF seed. It is secure for inputs 
fo, .-; ppp} C Zp under the nppr-DDHI assumption. This is a family of increasingly stronger 


assumptions which is assumed to hold for asymmetric bilinear groups. 


6.2.7 Range Proofs 


A range proof is not a real building block on its own, but rather a clever combination of a 


zero-knowledge scheme with a signature scheme. Nonetheless, in the rest of the thesis we 
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treat range proofs as if there were building blocks and therefore present their construction 
in this chapter. A range proof asserts in zero-knowledge that some secret Z,-element w is 
contained within the range fm, ..., my}. Clearly, such a statement only makes sense, if one pins 
down a fixed representation of Z,, reinterprets Z,-elements as ordinary Z-elements and then 
resorts to the normal <-relation over the integers. For the ease of presentation, we fix the 
representation Z, = (0,..., p — 1} C Z (see also Definitions 2.2 and 2.3). We need range proofs 


for two purposes: 


« To enable the blacklisting mechanism the users must prove during IssueWallet that they 
have chosen a particular component of their secret smaller than some fixed system 
parameter. This is a technical necessity such that calculating the DLOG remains feasible 


in case the users might be blacklisted eventually. 


* Also, a range proof could be included into a variant of Disburse such that the users are 
enabled to prove to have sufficient funds on their wallet without unveiling the actual 
balance. A scenario that might benefit from such an alternative variant of Disburse is 


described in Section 2.3.2 as a pre-payment system. 
We realize range proofs using Groth-Sahai by applying the signature-based technique of 
Camenisch, Chaabouni, and shelat [CCso8]. 
The Trivial Approach 


Firstly, we recap the trivial approach to prove that a secret wis within the range fm; ..., mu}. The 
verifier creates a signature for every element in (mj, ..., my} under his secret key and publishes 
these signatures. Then, the prover proves in zero-knowledge that he knows a signature for his 
secret value. Obviously, this approach only works if the range (mj, ..., mu} is small to keep the 
number of signatures limited. If the size of the range is proportional to size of the underlying 
group Zy, this method requires exponentially many signatures as log p € O(n) holds. 


An Approach for Aligned Intervals 


Camenisch, Chaabouni, and shelat [CCso8] exploit a q-ary representation of the secret w with 


at most Nmax positions to overcome this problem. For a fixed base 
2<q<p-1 (6.31) 
the maximal admissible number of positions Nmax is 
max = log, p]. (6.32) 
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and the largest integer that can be represented equals 
Ngay *= qox — 1. (6.33) 


The base q € N and the maximum number of positions Nmax € N are public design parameters 
and put into the CRS. Also, the verifier creates a signature for each of the possible digits 
10,...,q — 1} in advance and publishes these signatures. For the actual range proof, the verifier 
and prover first agree on the number of positions 7 € {1,... , max} they want to use. Then the 
prover secretly computes a representation w — >», wig! with wj € 10,...,.q— 1}. The prover 
shows in zero-knowledge that equality holds and that he knows a signature for each wy, i.e. 
that each w; is indeed a valid digit in {0, ...,q — 1}. The actual value of each digit remains secret 
and the verifier only learns that w can be represented with y < max positions. Hence, the 


approach is only applicable to intervals whose upper limits is aligned to powers of q. 


The General Case 


In order to prove membership in an arbitrary interval w € (mj ...,my} whose limits are not 
aligned to q-powers, the prover shifts the secret by a pertinent offset and then conducts 
two basic range proofs for two intervals that have properly aligned boundaries and whose 


intersection (after reverting the shifting) equals the original interval. 


Let 7 € {1, ... , ax] be defined as 
UE Llog, (mu -m)] +1 e q7! <m- m <q! (6.34) 


and define an offset value as 


o:=q —1, (6.35) 


i.e. o + 1 is the smallest q-power larger than the length m, — m of the interval. Please note, that 
q, Nmax and the boundaries of the interval mj, m, are known by both the verifier and the prover. 


Hence, the number of needed positions 7 and the offset value o are public, too. It follows 


w € im,...,myj 
e w- m € {0,...,my—m} 
= w- m € {0,...,0} n {my — m — o, ..., Mm mj (6.37) 
w — m € {0,..., 0} ^ 


e 
0t w-m, € {0,...,0} 
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$1 
3 Wa ees Moa €10,...,q0-1] :w-m- Y wa 
j=0 
= (6.37) 


n-1 
TWO a+ Waly €{0,...,g-1}: o+w-m, = Y wid 
j=0 


Unfortunately, the final two lines of equation (6.37) cannot be directly proven in zero-knowledge. 
For our particular instantiations of the building blocks commitments to Z,-elements are 
unveiled to the F,,-mapping of the committed value. This implies that equation (6.37) has to 
be projected by F,, as well. We denote the first ax q-powers of g by 


j . 
Qj:- gt? for j = 0, ..., Nmax — 1. (6.38) 


These constants are an F,,-mapping of all relevant magnitudes of the positional digit system. 


For an F,,-mapped secret W € G; the prover shows 


n-1 n 
_ w’ = 
3 wj, Wy EZ, : W 1 | [9;' ew mi (6.39) 
j-0 
]-1 » 
= w’ = 
Iwp,- Wi E Zp: W 1] lo” = gl Mau (6.40) 
j=0 


These are MSEs (cp. Section 6.2.1) and therefore perfectly fit into the Groth-Sahai proof sys- 
tem. Please remember, that besides Eqs. (6.39) and (6.40) the prover also has to show that 
Wop ees Wie Wo seers wi are valid digits in the range (0, ...,q}. Hence, the ZK-proof is addition- 


ally increased by 27 verifications of signatures that have been published by the verifier. 


Final Remarks with Respect to the Implementation 


Firstly, the efficiency of range proofs heavily depends on the representation of the elements 
with individual digits and then proofing statements about the digits in zero-knowledge. The 
design parameters q and Nmax are a trade-off between the number of signatures and the size of 
the NIZK statement. Please note, that the signatures can be pre-computed and re-used for all 
NIZKs. Hence, a larger q and a smaller 7,44, is usually beneficial. 

Secondly, due to rounding errors in max :— (log, p] there is a “margin” of Z,-elements 
{Nmax + 1, ..., p — 1} with Nmax := q max — 1 that cannot be represented by the positional number 


system. These Z,-elements encode “illegal” integers.’ Please note, that setting 74, (and Nmax: 


? In practical terms this means that only a subset of Z, can be used and “illegal” integers have to be avoided 


by the application. We claim, this does not pose a problem in practice. For a usual security level of 80 bit, the 
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resp.) to a larger value would foil the uniqueness of the representation w = yar wig! due 


to overflow issues. This would thwart the soundness of the range proof. 


Thirdly, whenever a constant Q; appears in a formula the party can compute g by itself. 


1 


In practice, it might be beneficial to pre-compute Q; and include them into the CRS such that 


they can be looked up quickly when needed. 
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group order p is a prime in the magnitude of 2754. If the base q = 16 is used (as we do in our implementation), 
this yields nmax = llog,¿2%*] = 63 and Nmax := 16% = 225. In other words, “only” integers between 0 and 275? 
can be represented, while integers between 22% and 2?°4 are “illegal”. For any naturally appearing balances/ 
prices the restricted space of representable elements is far more than sufficient. Although cleartext balances/ 
prices are restricted to a smaller domain, this does not weaken security as randomness and therefore ciphertexts/ 
commitments are still varying over the whole group. 


7 System Instantiation 


In this chapter we describe and define a real protocol psc that realizes our anonymous point 


collection scheme fpc- We say 


Definition 7.1 (Provably-Secure yet Practical Privacy-Preserving Point Collection 
Scheme) A protocol psc is called a Provably-Secure yet Practical Privacy-Preserving Point 
Collection scheme (P5C), if it UC-realizes Faye. 


The proof that psc is a UC-realization of fpc is given in Chapter 8. 

The style of the presentation follows the same structure as the presentation of the ideal 
model 9). in Chapter 4. First, we start to describe what information is stored locally be each 
party in Section 7.1 and then present a realization for each of the tasks in Sections 7.2 to 7.4. 
Again, an overview of all used variables can be found in the appendix for quick reference. 

Although zpsc is a single, monolithic protocol, the individual tasks are presented as if they 
were individual protocols. For typographic reasons we split their presentation into a wrapper 
protocol and a core protocol. Except for a few cases, there is a one-to-one correspondence 
between wrapper and core protocols. The wrapper protocols have the same input/output 
interfaces as their ideal counterparts and describe steps that are executed by each party locally 
before and after the respective core protocol. The wrapper protocols pre-process the inputs, 
parse the previously stored state from local memory which also includes to load individual keys, 
post-process the output after the core protocol has returned, persist the new state, and interact 
with other UC functionalities. The core protocols describe the actual interaction between 
parties and what messages are exchanged. This dichotomy between wrapper and core protocols 


is lifted in the following cases: 


(1) We give an algorithm for the setup of the system (cf. Fig. 7.2) which explains how the 
CRS is generated. Naturally, there is no wrapper protocol, because setup of the CRS is 
not part of our protocol, but part of the setup assumption and provided by Fes. 


(2) We describe a helper algorithm VerifyWallet (cf. Fig. 7.30). This algorithm has no purpose 


on its own, but simple collects some shared code of multiple tasks. 
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(3) The tasks DetectDS, VerifyGuilt and ProveParticipation (cf. Figs. 7.23, 7.24 and 7.29) 
are not split, because they are so short that doing so would run contrary to a concise 


presentation. 


The realization psc lives in the (Finsg, Fi» f ns)-hybrid model. Fnsg is used for messaging 
between parties, Fpp is used to publish public keys for the parties, and Fcrs is a trustworthy 
source for a common reference string. We refer the reader to Sections 3.4 and 3.5 for more 
details. In the following, the wrapper protocol for each task typically interacts with these 
setup functionalities and passes/accepts required information to/from the core protocol. The 
core protocols have no knowledge about the setup functionalities, but they implicitly use 
the messaging capabilities of Fmsg which has appropriately been initialized by surrounding 


wrapper protocols in advance. 


71 The Local State of the Parties 


While in the ideal model all information is kept in a single, pervasive, trustworthy database 
TRDB, no such database exists in the real model. Instead, the state of the system is distributed 
across all parties. Figure 7.1 depicts what is stored by which party. After a description of each 
party's local state in Sections 7.1.1 to 7.1.3, the instantiation of the tags (cf. Section 4.1.2) is 
detailed out in Section 7.1.4. Although these tags are not a direct part of a party's local state, 


they are passed between parties for synchronization and thus contributes to the local state. 


7.3333 Local State of a User 


We start with a description of the user's state because the wallet is the central concept of our 
P5C scheme. A wallet is created during IssueWallet locally stored by the user and subsequently 
updated. If the inner components of a wallet are understood, the rest follows naturally. A 


wallet is of the form 


< t t 
T= (s, p, xt À, aqp Cupd» Aund» Capd Cero, Chiyo dix Op; b, UP” ). (7.1) 


Some of the components are fixed after issuing, some change after every transaction. The most 
essential elements are two signed commitments cg,, Cupa with cg, binding the fixed part of a 
wallet and Cy q binding the updatable part. 

The fixed part consists of the wallet ID A, the user attributes aqy, the fixed commitment cf,,, its 


corresponding opening dg, and a signature og, which created by the operator when the wallet 


130 


7.1 The Local State of the Parties 


UC-Protocol zp;c 
I Local State 


(1) The operator internally records: 
* A public and private key (pko, sko). 
e A self-signed certificate certo. 
e A partial, set-valued and pairwise disjoint mapping Solo, assigning a set of 


blacklisted fraud-detection IDs to a blacklisting tag: 
Foto, E Oy > p (P) , cg rm blo, 


(2) Each PoS internally records: 
* A public and private key (pkp, skp). 
* A certificate certp signed by the operator. 
(3) Each user internally records: 
* A public and private key (pk, ,, skqy). 
* A set {r} of the most recent states of all personal wallets. 
+ A mapping fpp assigning the hidden part of a prove-participation tag Ypp to a 
prove-participation tag «pp: 
Jop * 2pp > Ppp» pp > Vpp 


(4) The dispute resolver internally records a public and private key (pk pp, skpg). 


IL Behavior 


e Dispute Resolver Registration (Fig. 7.3) e Disbursement (Fig. 7.21) 
e Operator Registration (Fig. 7.5) * Double-Spending Detection (Fig. 7.23) 
* Point-of-Sale Registration (Fig. 7.7) « Guilt Verification (Fig. 7.24) 


* User Registration (Fig. 7.9) e Wallet Blacklisting (Fig. 7.25) 


e Point-of-Sale Certification (Fig. 7.11) - Balance Recalculation (Fig. 7.27) 


= Wales esting GSP. qug) « Prove of Participation (Fig. 7.29) 


« Deposition (Figs. 7.16 and 7.17) 


Figure 7.1: The Protocol zpsc - Local State of Parties and Overview of Tasks 
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is issued. The fixed commitment cg, = Commit(A, skq,)’ pins users down to the wallet ID A 
and their secret key skq,. The signature og, — SIC.Sign(skD*, (cg, 4q/)) is initially created by 
the operator, ties together cg, and aq, and also gives testimony that the wallet is valid. 

The updatable part consists of the serial number s, the fraud-detection ID q for the current 
transaction, the transaction counter x" for the next interaction, the updatable commitment 
Cupa» Its corresponding opening dapa a signature Cupa which created by a PoS, a PoS certificate 
certp, the balance b, and the double-spending mask u"! for the next transaction. The updatable 
commitment Cupd = Commit(A, b, um. xnext) binds together the wallet ID A, the balance b, some 
user-chosen mask u; to generate consistent double-spending tags in the next transaction and 
the future transaction counter x"*!, The wallet ID A is contained in the updatable commitment 
in order to link it with the fixed commitment. The signature Capd €^ SIC.Sign sk?" (Capa: s)) 
ties C„pq to a serial number s and is re-created by a PoS in every transaction. It is valid under 
the PoS’ public key which is deposited in certp (cf. Section 7.1.2). 

Note, that the fraud-detection ID q itself is not contained in the updatable commitment as it 
is determined by (A, x) and thus is pinned down indirectly. The wallet ID A serves a PRF key 
and the fraud-detection ID of the current transaction is calculated as y := PRF(A, next — 1). 
This choice of the fraud-detection ID has the advantage that the different states of a wallet are 
untraceable as long as A remains secret, but becomes traceable if A is unveiled. 

The remaining information which is stored by a user is rather simple (cp. Fig. 7.1). A user 
stores a public-secret key pair (pk, skq,) for the purpose of identification. Additionally, a user 
locally manages a lookup table fpp which associates a hidden counterpart Ypp to each prove- 
participation tags «py that has been created in the scope of Disburse (cp. Section 7.3.3). For 
details on this not yet introduced hidden complement ypp see Section 7.1.4. Users have to look 
up the hidden counterpart Ypp when they are confronted with one of their previous prove- 


participation tag “pp in the scope of ProveParticipation (cp. Section 7.4.4) again. 


7.1.2 Local State of a Point-of-Sale 


The local state of a PoS is a subset of what the operator stores and therefore described first. A 
PoS stores a public-private key pair (pkp, skp) and a certificate cert. The key pair is of the 


form 


pkp = (pkeP4, pks, pk?) skp :— (skzP, sls, skEP) (7.2) 


1 By abuse of notation, we sometimes ignore the opening or decommitment value dg, which is also an output of 


Commit(-). 
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and consists of three key pairs of an EUF-CMA secure signature scheme: (kPt, sky) to sign 
the updatable part of a wallet, (pk, skp) to sign recalculation tags and (pk??, skEP) to sign 


prove-participation tags. The certificate is of the form 


certp = (pkp, ap, og") (7.3) 


and consists of a signature f°" which is issued by the operator on the PoS’ combined public 
key pkg and its attributes ap. A PoS obtains its certificate in the scope of CertifyPOS (cp. 
Section 7.2.3). 


7.1.3 Local State of the Operator 


The local state of the operator is a superset of what a PoS stores, because the operator can also 
act as a PoS. Likewise, the operator stores a public-private key pair (pkp, skp) and a self-signed 
certificate certo. The key pair is of the form 


pko = (pki, pee DROP, perros, ok) sko = (kÈ, st sep, ee, ee) 
(7.4) 


and the signature key pairs (propa, sep) and (pkey, sks?) serve the same purpose as in 
Section 7.1.2. On top, the signature key pair (pk Bs, sk’) is used to sign the fixed part of a wallet, 


cert cert 


the signature key pair (pkg , sko 


rc,enc 


key pair (pko , sk) is used to collect encrypted recalculation tags from the PoSes. 


) is used to issue certificates for PoSes and the encryption 


The map For, manages pairwise disjoint sets of fraud-detection IDs of blacklisted wallets. 
After a successful execution of IssueWallet the secret wallet ID A is fixed. This also implies that 
the set (9 „} of fraud-detection IDs which are used by the particular wallet are pre-determined 
but is of course unknown to the operator. Remember, the wallet ID A serves as PRF seed (cp. 
Section 7.1.1). At the end of IssueWallet (cp. Section 4.3.1) the operator obtains a blacklisting 
tag cy which allows the operator to recover the set {p} ,}. The map foi, can be in one out of 


three possible states per «yy. 


(1) "For, (yj) is undefined”: The blacklisting tag cj has not been generated, i.e. no wallet 
with this blacklisting tag has been issued. 


(2) "fy, (9j) = 2”: A wallet has been issued for the blacklisting tag «yj, but has not been 
blacklisted. 


(3) “Fois ov) = bla, + Ø”: A wallet has been issued for the blacklisting tag œp; and black- 
listed. The blacklist is blg. 
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For an arbitrary, but fixed cj the map foi, transits from state (1) to (2) at the end of IssueWallet 
(cp. Section 7.3.1) and from (2) to (3) at the end of BlacklistWallet (cp. Section 7.4.2). Note 
that fy), is pairwise disjoint only with overwhelming probability. Each of the sets blg, = 
{PRF(A, 0), ..., PRF(A, x,ounq)} has finite size Xhouna + 1 and there are only polynomially many 


of them with uniformly drawn À while the image of PRF is exponentially large. 


73.4 Instantiation of Tags 


As detailed out in Section 4.1.2, the main tasks IssueWallet, Disburse and Deposit generate 
various sorts of tags, namely blacklisting tags «yj, double-spending tags c, recalculation tags 
Orc and prove-participation tags cy. These tags are used to periodically synchronize the local 
state of the parties and each sort of tags supports one of the utility tasks (cp. Section 4.1.2). 
As the tags are not specific for a single task but link different tasks, this section gives an 
integrated explanation. As a common characteristic, three of these tags come as pairs with 
a hidden counterpart Wy, Y; and Ypp, resp”, which are not described in Section 4.1.2 as their 
implementation is specific to the realization psc. The tags are output to the environment, 
passed around and thus part of the public interface, while their hidden counterparts are kept 


secret from the environment. 


Blacklisting Tags 


A blacklisting tag «yj is output to the operator at the end of IssueWallet and allows with 
the consent of the dispute resolver to recover the sequence of all fraud-detection IDs blg — 
(Prod xe ee which are used by the wallet with the (secret) wallet ID A. Further remember, 
that the wallet ID does not only uniquely identifies the wallet, but also serves as the seed for 
the Dodis-Yampolskiy (cp. Section 6.2.6 and [DYo4]) PRF and determines the fraud-detection 
IDs by 9, x := PRF(A, x). 

At first sight, the blacklisting feature could be implemented as a simple form of key-escrow 
mechanism. Ideally, the hidden blacklisting tag y; := A would be set equal to the wallet 
ID and the user would encrypt jy; under the public key pkpp of the dispute resolver as 
py — Enc(pk pp» Vj) which is then sent to the operator for later use. However, two issues need 


to be considered: 


(1) The wallet ID A is jointly chosen by the user and the operator by a Blum Cointoss and 
thus consists of two shares A’, A” (cp. IssueWallet in Section 7.3.1). If only the user chose 
it, an adversary could tamper with recalculations and blacklisting, as well as with double- 


spending detection (e.g., by re-using the same wallet ID for different wallets). 


? Conceptionally, there is also a hidden part for wgs, namely the DS mask u, (see later), but there is no need to store 


it and hence no separate symbol has been introduced although this causes a lack of symmetry. 
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(2) The wallet ID is part of the fixed commitment cg, of the wallet (cp. Section 7.1.1). 


Hence, the user has to prove to the operator that the encrypted value in cj and the committed 
value in cg, are equal and consistent to the Blum Cointoss. For practical reasons, we use 
Groth-Sahai NIZK proofs (cp. Section 6.2.1 and [GSo8]) and structure-preserving, shrinking 
commitments (cp. Section 6.2.2 and [Abe+15]). In order to not quash practical efficiency due to 
a generic Cook reduction, we would need an encryption scheme whose message space equals 
the key space of the PRF (i.e., Z,) and which is compatible to the GS-NIZK proof system (i.e., is 
algebraic). Unfortunately, we are unaware of such an encryption scheme? 

Instead, we use a variant of a CCA-secure structure-preserving encryption scheme for vectors 
of G,-elements which we adopted to our algebraic setting (cp. Section 6.2.4 and [Cam+11]). 
This makes it impossible to directly decrypt the original wallet ID A € Z, and to recover A 
from gà due to the hardness of the DLOG problem in G4. Therefore, we apply the following 
workaround. Users split their share A’ into small chunks 45,...,À; , € {0,...,B — 1} such that 
X= X Aj : B for some base B. The base B is chosen in a way that it is feasible for the dispute 
resolver to recover A/ from gi by brute-force in a reasonable amount of time (e.g., B = 232), 


The user creates the hidden blacklisting tag as 
, , ^" 1 , Ai 
Wc ENCI.Enc(pk pp, (Aj. App A ‚Pkq)) with Aj = gy (7.5) 
and the operator complements it to the blacklisting tag as 


Op = A”, Yo) (7.6) 


The CCA-secure ciphertext y includes the user's key pk, to rule out malleability attacks. 
Otherwise, a malicious operator could potentially trick the dispute resolver into recovering the 


trapdoor for a different (innocent) user. 


Double-Spending Tags 


Our double-spending detection mechanism utilizes a well-known technique from the (offline) 
e-cash literature. The secret user key is hidden in the slope of a line in the plane. At every 
transaction, the operator challenges the user for a point on the line. The operator picks the DS 
challenge u, and the user replies with t := uz - skqy + u, mod p. The concrete line is masked by 


the DS mask u, which encodes the line’s ordinate and is secretly chosen by the user. 


? Note that Paillier encryption works in a different algebraic setting and cannot easily be combined with Groth-Sahai 


proofs. 
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As long as each state of a wallet is only used once, each time a different DS mask u; and thus 
a different line is used and no information about sk4, is unveiled. In case of a double-spending, 
the same DS mask is used, the operator learns two points (ut), (5,1) on the same line and 
can restore the user's secret key via sky, :— (t — t^)/(u5 — uj) mod p. In order to force the user 
to use the same DS mask u; in case of a double-spending, the DS mask for the next transaction 
is fixed as up! in the previous transaction and put into the updatable commitment Cupd of the 
wallet (cf. Section 7.1.1). 


The double-spending tag has the form 


Was = (Qt, uz) (7.7) 


and also includes the fraud-detection ID q to identify matching double-spending tags which 
have been created for the same wallet state. Moreover, the secret user key does not only allow 
to lookup the user's PID for the public key pkg, := ga, but also serves as a proof of guilt 
7 := sk4, due to the hardness of the DLOG in G;. 


Recalculation Tags 


The tasks Deposit and Disburse output recalculation tags that allow the operator to recal- 
culate the true balance of a wallet given that the operator has recovered the blacklist blg = 
(Ad xeto,....x, 3 of fraud-detection IDs of the wallet before. The recalculation tag wrc and 


its hidden complement y, are simply constructed as 


re = (8,9, p, pkp» Ore) (7.8) 
Wye — ENC2.Enc(pk ^ 5, Yre) (7.9) 


The fraud-detection ID ọ and price p are needed for the obvious reason that the operator needs 
to match p with the set blg and to recalculate as balance as the sum of all prices. The serial 
number s is included to enforce uniqueness of the tags for formal reasons, if all other attributes 
are equal. This might happen if the same user commits double-spending at the same PoS and 
also obtains the same price. The signature o,. and the encryption realize an authenticated 
and confidential channel despite the fact that the framing protocol, i.e. the environment, is in 
charge to transport recalculation tags from the PoSes to the operator. The signature on the 
triple (s, p, p) under the secret key skp of the PoS rules out that the environment can inject 
fake recalculation tags in the name of an honest PoS. The encryption is required, because the 
price p might infringe upon a user's privacy and is not leaked by the ideal model as long as the 


user, the involved PoS and the operator are honest. 
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Prove-Participation Tags 


At the end of the task Deposit a prove-participation tag «yy is output to the user and the PoS 
which allows the user to prove to have participated in this transaction. The recalculation tag 


@pp and its hidden complement Ypp are constructed as 


pp = (EP, Opp: dy.) (710) 


Opp *= Cpk,, (7.11) 


with (epi, doky) e C2.Commit(crs®),,, skqj) being a commitment on the user's key and Opp = 
SIG.Sign(skP», Cok) a signature on the commitment that is valid under the public key of 
PoS which took part in the transaction. The principle idea is that the hiding property of the 
commitment, i.e. the “public” prove-participation tag «pp asserts anonymity. But when the 
suspected user is confronted with wp, again and summoned to prove its participation with a 
particular PoS, only the legitimate owner of wp, who has securely stored Ypp can unveil to the 


correct identity during the task ProveParticipation. 


72 Setup Tasks 


As in the system definition (cp. Section 4.2) all parties need to register themselves with a public 
key before they can participate in the system and PoSes needs to certified. In addition, the 
whole system needs to be setup once. The latter has no counterpart in the ideal model and is 


realized through the setup functionality Fers- 


7.24 System Setup 


To setup the system once (see Fig. 7.2), the public parameter crs must be generated in a 
trustworthy way. The CRS crs consists of a description of the underlying algebraic framework 
gp, a splitting base B and the individual CRSes for the cryptographic building blocks. We 
assume that the CRS is implicitly available to all protocols and algorithms by means of Feps. 


7.2.2 Registrations 


The tasks RegisterDR (cp. Figs. 7.3 and 7.4), RegisterOp (cp. Figs. 7.5 and 7.6), RegisterPOS (cp. 
Figs. 7.7 and 7.8) and RegisterUser (cp. Figs. 7.9 and 7.10) are realized in the obvious way. The 
respective core protocols run the key generation algorithms of the underlying building blocks 
and return a combined public-private key pair. After that the wrapper protocols register the 
public key at the bulletin board Fpp. 
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Setup(1”, B) 


gp = (Gi, Gz, Gr, €, p, 81,82) € Setup(1") 
crs, - C1.Setup(gp) 


crs®, — C2.Setu p(gp) 


crs), — C3.Setup(gp) 

ers, — C4.Setup(gp) 

CFSpox €- POK.Setup(gp) 

ers = (gp, B, crs), ers, ers. crs, CPSpok) 


return crs 


Figure 7.2: System Setup Algorithm 


UC-Protocol zpsc (cont.) - Task RegisterDR 

DR input: (register) 

(1) If a key pair (pk pp, skpg) has already been recorded, immediately output 

(registered) and halt. 

(2) Obtain CRS crs from Feps. 

(3) Run (pk pp, skpg) — RegisterDR(crs) (see Fig. 7.4). 

(4) Record (pk pp» skpg) internally and call Fpp with input (register, pk pp). 
DR output: (registered) 


Figure 7.3: The Protocol zpsc (cont. from Fig. 7.1) - Task RegisterDR 


RegisterDR(crs) 


(1) (2) (3) (4) = 
parse (gp, B, crstom, CFScom, CrStom» Cl'Scom; CTS yok) := crs 


(pk pg» skpg) <— ENC.Gen(gp) 


return (pk pp SKpr) 


Figure 7.4: The Core Protocol for Task RegisterDR (used by Fig. 7.3) 
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UC-Protocol zpsc (cont.) - Task RegisterOp 


Operator input: (register, ag) 
(1) Ifa key pair (pko, sko) has already been recorded, immediately output 
(registered) and halt. 
(2) Obtain CRS crs from Fers. 
(3) Run (pko, sko, certo) — RegisterOp(crs, ay) (see Fig. 7.6). 
(4) Record (pko, sko) and (certo) internally and call Fpp with input (register, pko). 
Operator output: (registered) 


Figure 7.5: The Protocol zpsc (cont. from Fig. 7.1) - Task RegisterOp 


RegisterOp(crs, ao) 


1 2 3 4 - 
parse (gp, B, crsa, ers, ers crs on, CFSpok) = crs 


(pk&, sk) - SIG.Gen(gp) 

(pk, sk") d= SIG.Gen(gp) 

(pki, sk???) — SIG.Gen(gp) 

(pk'**, skiSS8) — SIG.Gen(gp) 

(pie. sks) e ENC2.Gen(gp) 

(pkg, sko) = (Pko pko > pkg", pkg", pkg), Ko sko”, O) 
og e SIG.Sign(sko ", (pk?*, ao)) 

certo :— (pk, 40.05.) 


return (pk, Sko, certo) 


Figure 7.6: The Core Protocol for Task RegisterOp (used by Fig. 7.5) 


UC-Protocol zpsc (cont.) - Task RegisterPOS 


PoS input: (register) 
(1) If a key pair (pkg, skp) has already been recorded, immediately output 
(registered) and halt. 
(2) Obtain CRS crs from Fers. 
(3) Run (pkg, skp) — RegisterPOS(crs) (see Fig. 7.8). 
(4) Record (pkg, skp) internally and call £y, with input (register, pkp). 


PoS output: (registered) 


Figure 7.7: The Protocol zpsc (cont. from Fig. 7.1) - Task RegisterPOS 
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RegisterPOS(crs) 


parse (gp, B, crn, crs), ers crs, CFSpok) = Crs 
(pk, sk’) < SIG.Gen(gp) 

(pkp, skp) <— SIG.Gen(gp) 

(pk? , sKEP) — SIG.Gen(gp) 

(pk, skp) = ((pkyP", pkp, PKP), (sk, skp, sk?) 
return (pk,,, skp) 


Figure 7.8: 


The Core Protocol for Task RegisterPOS (used by Fig. 7.7) 


UC-Protocol 7p5c (cont.) — Task RegisterUser 


User input: (register) 
(1) Ifa key pair (pk, skq,) has already been recorded, immediately output 
(registered) and halt. 
(2) Obtain CRS crs from Feps. 
(3) Run (pk, ,, skqy) — RegisterUser(crs) (see Fig. 7.10). 
(4) Record (pkq,, skq,) internally and call Fpp with input (register, pkz,). 
User output: (registered) 


Figure 7.9: 


Figure 7.10: The Core Protocol for Task RegisterUser (used by Fig. 7.9) 
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The Protocol zpsc (cont. from Fig. 7.1) - Task RegisterUser 


RegisterUser(crs) 


(1) (2) (3) (4) T€ 
parse (gp, B, crscom, Cl'Scom» C''Scoms CFScom) C'Spok) *= Crs 
R 
ska, = Z, 


pk, = gi" 
return (pk, Sku) 


7.3 Main Tasks 


The keys of the operator, a PoS and a user are described in Sections 7.1.1 to 7.1.3. The DR 
generates a key pair (pk yp, sk pr) for an IND-CCA secure encryption scheme. The key pk pp 
is used to deposit the secret wallet ID and PRF key A in encrypted form in the wallet-specific 


blacklisting tag c which allows to link this wallet’s transactions in case of a dispute. 


7.2.3 Point-of-Sale Certification 


The task CertifyPOS (cp. Figs. 7.11 and 7.12) is executed between a PoS and the operator when 
a new PoS is deployed into the field. At the end of the task the PoS has obtained its certificate 
which is locally stored. It contains the PoS’ public key pkg, its attributes ap (which are chosen 
by the operator), and a signature on both, generated by the operator using sko n, 

Remember that it is advisable to encode some sort of limited time of validity into ap to 
mitigate the impact of stolen or otherwise compromised PoS which may be unattendedly placed 
in the field (cp. Section 2.4). This implies that CertifyPOS has to be run repeatedly to refresh 


certp from time to time (cp. Section 4.2.2). 


7-3 Main Tasks 


This section describes the realization of main tasks IssueWallet, Deposit and Disburse. Al- 
though the tasks are presented in that order, the individual steps and messages of each task 
are not described in temporal order, but specific elements are explained in a semantic context 
across messages. We refer the reader to the figures for a temporal order of messages. Also, the 


principle structure of a wallet (cp. Section 7.1.1) and the tags should be known (cp. Section 7.1.4). 


7.31 Wallet Issuing 


This task IssueWallet (cp. Figs. 7.13 to 7.15) is executed between a user and the operator to 


create a new wallet with a fresh wallet ID A and balance 0. It fulfills four objectives: 
(1) Jointly computing a fresh and random serial number s for this transaction. 


(2) Jointly computing a fresh and random wallet ID A for the user that is only known to the 


user. 
(3) Generating a blacklisting tag œ that stores the wallet ID A in a secret form. 
(4) Assembling all components for a new wallet for the user. 


For the first objective, both parties randomly choose shares of the serial number s’ € G, and 
s" € G}, resp., which together form the serial number s := s’ -s”. To this end, the parties engage 


in a standard Blum coin toss in the messages 2-4. 
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Similarly, the parties run half of a Blum coin toss for the second objective in the messages 1 
and 2. As the user starts and the coin toss is prematurely stopped after the second message, the 
wallet ID à := A4 +A” € Zp is fixed and known by the user, but remains secret to the operator. 

After the wallet ID A has been pinned down, the user prepares the escrow of A in the 
blacklisting tag for the third objective. The user deposits the split chunks (A7 Jieto,.t-1) of the 
user's share A’ in encrypted form in the hidden blacklisting tag ypj, sends it to the operator in 


message 3, the operator augments it by the operator's share A” to form the complete blacklisting 


UC-Protocol zp;c (cont.) - Task CertifyPOS 


PoS input: (certify pos) 
(1) At the PoS side: 
(a) Load the internally recorded (pkg, skp).+ 
(b) Receive pkg from the bulletin-board Fpp for PID pido. 
(c) Call Finsg with (establish-session, ident, pido, certify_pos). 
(2) At the operator side side upon receiving (establishing-session, ssid, pidp, 
certify pos) from Finsg: 
(a) Load the internally recorded (pko, sko)+ 
(b) Receive pkp from the bulletin-board Fp, for PID pidp.+ 
Operator output: (certifying pos, pid) 
Operator input: (certifying pos,ap) 
t the operator side: Ca with (accept, ssid ). 
(3) At the op ide: Call 75,4 with ( d) 
(4) At the PoS side: Receive (accepted, ssid) from msg: 


(5) Both sides: Run the code of CertifyPOS between the PoS and the operator (see 
Fig. 7.12) using (send, ssid, ...) of Fmsg for messaging: 


((certg),(0K)) — CertifyPOS (P(pk, , Pkp), O(pko, sko, PKp, ap)) . 


(6) At the PoS side: 
(a) Parse ap from certo. 
(b) Record certp internally. 
(c) Call 75,4 with (close, ssid). 
(7) At the operator side: Receive (closed, ssid) from Fingg. 
PoS output: (certified_pos, ap) 
Operator output: (certified_pos) 


+ Tf this does not exist, abort. 


Figure 7.11: The Protocol psc (cont. from Fig. 7.1) - Task CertifyPOS 
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P(pk, pkp) 


O(pk,,, sko, Pk, ap) 


parse (pk, pk. pre”, pki, pk5^^) = pko 


parse (DK, pk, pk m ph pk5^7) = pk, 


parse (ski, sk", ska a ska, sko 5) = sko 
ag <— SIG.Sign(sk5" , (pkp ap)) 
certo :— (pkp, ap, og 


certp 


parse (pkp, ap, of") := certp 
if SIG. Vfy(pk5", 05", (pkp, ap)) = 0 
return L 


return (certp) return (OK) 


Figure 7.12: The Core Protocol for Task CertifyPOS (used by Fig. 7.11) 


tag «y and locally stores cj; > Ø in Sonn, to mark the blacklisting tag as legitimately issued 
and not blacklisted. For a detailed explanation on y, «yj see Section 7.1.4. 

For the last objective, the user generates the fixed and updatable commitment cg, Cupd> 
resp., which are then signed by the operator (see messages 3-4). See Section 7.1.1 for a detailed 
description of the structure ofa wallet. In order to show that these commitments are constructed 
correctly, the user uses P1 to compute a proof z for a statement stmnt from the language e 


defined by 


3 A, A Ay Ares A 11,19 € Zo; 
„| AMA AL SUI, dies dapa dig € Gi; 
pkey C1.Open(crs(),, (A, pk, ), ix dg,) =1 
Pkpp C1.Open(crs(),, A 81); Cupa» dapa) =1 
Vii C3.Open(ers on, A^, c^ igo d^) =1 
10) = J] x | | Yu = ENCLENC(pk pps (Ags At A” Pkapırın) adi 
Cupd A=N+A" 
Ga | | A= eh. A’ eat 
A" y= y A . Bi 
A" vi € (0,...,t— 1] : 
AM €10,...,B- 1} 
A 
Ai =g 


This proof system also asserts that the hidden blacklisting tag y, has been created correctly. 


143 


7 System Instantiation 


UC-Protocol zpsc (cont.) - Task IssueWallet 


User input: (issue wallet) 
(1) At the user side: 


(a) Load the internally recorded (pk, skq).+ 
(b) Receive pk, from the bulletin-board Fpp for PID pid, 
(c) Receive pk pp from the bulletin-board 7; for PID pid pg- 
d) Call Faso with (establish-session, ident, pid, issue wallet). 
msg pido 
(2) At the operator side upon receiving (establishing-session, ssid, pid, ;, 
issue wallet) from Fingg: 
(a) Load the internally recorded (pko, skg).+ 
(b) Load the internally recorded certo. 
(c) Receive pk pp from the bulletin-board Fpp for PID pid pj. 
(d) Receive pk, from the bulletin-board Fpp for PID pid, ,.- 
Operator output: (issuing wallet, pid,,,) 
Operator input: (issuing wallet,a4j) 
3) At the operator side: Call 75,,, with (accept, ssid). 
p msg 
4) At the user side: Receive Fx with (accepted, ssid). 
msg 
(5) Both sides: Run the code of IssueWallet between the user and the operator (see 
Figs. 7.14 and 7.15) using (send, ssid, ...) of Fmsg for messaging: 


(o, (s, oy) < IssueWallet CU pk pp: pkqp ska), OCpk pp, sko: Pkap au certo)) . 


(6) At the user side: 
(a) Run the code of VerifyWallet(pk „, pk, T) (see Fig. 7.30). 
(b) If VerifyWallet returns 0, output L and abort. 
(c) Record r internally. 
(d) Parse s and aq, from r. 
(e) Call Fnsg with (close, ssid). 
(7) At the operator side upon receiving (closed, ssid) from Fmsg, append «y; > Ø to 
fi blo,” 
User output: (issued_wallet, s, aq,) 
Operator output: (issued_wallet, s, cj) 


+ Tf this does not exist, abort. 


Figure 7.13: The Protocol zpsc (cont. from Fig. 7.1) - Task IssueWallet 
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U(PK pps pk, Sku) O(pk pp Skos PK, au, certo) 


parse (sk 5, sks", 


re,sig recency . — 
sko >, sko  ):= sko 


R R 
s «—- 6, s" EG; 


2? È {0,...,B— 1} for i € lu... c1] 


t1 
= XB X EZ, 
(ci dhia) S C3.Commit(crsQ),, A”) (c, de.) = CA. Commit(crs®,, s" 
Chid 
— 


certo, Aqy, Chr, A” 


d 
parse (pk, ao, ag") := certo 


if SIG. Vfy(pk"?"*, age, (pr, ag) = 0 


return L 
A= N +A" 
A= gi, Al gi’, A” = gp weg 


N := git for i € (0,...,£— 1} 
Fb, & Z, 
Y, €- ENC1.Enc(pk pp» 
(Ay, Aca A”, pku): ror) 
uet ez, 
(Gigs dex) € C1.Commit(crs,, (A, sky) 
(Cupar daga) — C1.Commit(crs®,,, 
(A, 0, upet, 1)) 
stmnt := (pk ap PK pgs Vor Cix Copa Chios A”, A”) 
wit :— (AN Ay... Pt prs; A, A’; 


A, ... AL. DE p [T diia) 


Te bsp. stmnt, wit) 


" 
S, Yor Clix» Cupd» T 


upd 
sko >» 


Figure 7.14: The Core Protocol for Task IssueWallet (used by Fig. 7.13) 
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S’, Vols Cix Capa: T 


" 


si=s 
stmnt := (pk, pk ps Yi 
Cfixs Capd» Chid’ A", A") 


S 


if P1.Vfy(ers,og, stmnt, 1) = 0 
return L 

Op = SIG.Sign(sk*, (cg, 4q,)) 

Supa — SIG.Sign( sk", (Capas s) 


"EP 
S, Mors Ofix» upd 


if C4.Open(ersQ),, s”, 0%, d%,) = 0 


return L 
sı= s.s" 
T = (s, PRF(A, 0), 1, À, aqq, Capa» dapa Oupa» 

certo, Cix dix Oax 0, UNA Oy = A”, Yon) 
return (7) return (s, ay) 


Figure 7.15: The Core Protocol for Task IssueWallet (cont. from Fig. 7.14) 


7.3.2 Deposition 
The task Deposit (Figs. 7.16 to 7.20) is executed between an anonymous user and a PoS to 


deposit points on a wallet owned by the user. It serves the following objectives: 


(1) Jointly computing a fresh and random serial number s for this transaction. 


(2) Determine the price p to be deposited. 
(3) Assembling all components for an updated wallet for the user. 


(4) Generating (a) a double-spending tag “ys (b) a recalculation tag w,. and (c) a prove- 


participation tag @pp- 


As in Section 7.3.1 for IssueWallet the first objective is implemented by a standard Blum 


cointoss in the message 1-3. 

To achieve the second objective, the task is interactive. After the user has send the attributes 
aq üp which are required to determine the price p in message 2, those are output to the PoS. 
The PoS restarts the second part of Deposit with the price as input which is then sent back to 


the user in message 3. 
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UC-Protocol zp;c (cont.) - Task Deposit, Part 1 


User input: (deposit, sP'*", pidp) 
(1) At the user side: 
(a) Load the internally recorded (pk, skqu).- 
(b) Receive pk, from the bulletin-board Fpp for PID pidy.+ 
(c) Load the internally recorded token TP" for serial number sP'*V .- 
(d) Call msg with (establish-session, anon, pidp, deposit). 
(2) At the PoS side upon receiving (establishing-session, ssid, 1, deposit) from msg: 
(a) Load the internally recorded (pkp, skp).* 
(b) Load the internally recorded cert. 
(c) Receive pkg from the bulletin-board Fpp for PID pido. 
PoS output: (depositing) 
PoS input: (depositing, blø) 
(3) At the PoS side: Call 75,4 with (accept, ssid). 
(4) At the user side: Receive (accepted, ssid) from msg: 


(5) Both sides: Run the code of Deposit Part 1 between the user and the PoS (see 
Figs. 7.18 and 7.19) using (send, ssid, ...) of Fmsg for messaging: 


OK, Ulpk „, pk, y, skq,, TP’), 
| ) - Deposit, ( Pko: Pky u n 


(s, aq, a P(pko; certo, skp, bla) 


PoS output: (depositing, s, aqp db.) 


+ Tf this does not exist, abort. 


Figure 7.16: The Protocol zpsc (cont. from Fig. 7.1) - Task Deposit, Part 1 


For the third objective, the homomorphism of the commitment scheme is exploited. Also see 
Section 7.1.1 for a detailed description of the wallet. The user creates a re-randomized version 
c, „q Of the previous updatable commitment cP""". The commitment c/ . , contains the same 

up upd upd 
values as Cod except for a fresh DS mask u?¢*t (see next paragraph) and is sent to the PoS in 
message 2. Re-randomization enables unlinkability. The PoS applies the homomorphic update 
c" toc? ‚to deposit p points on the balance and to increase the transaction counter x by 1. 

upd upd 
The combination of serial number s and the modified updatable commitment Cy q is signed by 
the PoS with Cupd and both are sent back to the user in message 3. 

To generate the double-spending tag c, for the current transaction, the PoS challenges 


the user with uz in the first message. In the second message, the user responds with the DS 


147 


7 System Instantiation 


UC-Protocol zpsc (cont.) - Task Deposit, Part 2 


PoS input: (depositing, p) 
(6) Both sides: Run the code of Deposit Part 2 between the user and the PoS (see 
Fig. 7.20) using (send, ssid, ...) of Finsg for messaging: 


(Cr, Opp» pp); (Ods: Ores Opp)) < Deposit; (UO, P(p)) 


(7) At the user side: 

(a) Run the code of VerifyWallet(pk,, pk, T) (see Fig. 7.30). 
b) If VerifyWallet returns 0, output L and abort. 
c) Append oy, > Ypp to fpp and record r internally. 


a a 


d) Parse s, certo, p and b from 7. 


~ má 


e) Parse ap from certo. 
(f) Call Fnsg with (close, ssid). 
(8) At the PoS side: Receive (closed, ssid) from Finsg. 
User output: (deposited, s, ap, p, b, (pp) 
PoS output: (deposited, gg, rc, Opp) 


+ Tf this does not exist, abort. 


Figure 7.17: The Protocol zpsc (cont. from Fig. 7.1) - Task Deposit, Part 2 


response t := skqj- uz + uj mod p and the current fraud-detection ID g := PRF(A, x) which has 
been calculated by the user in the beginning. This gives the PoS all information to construct the 
double-spending tag c, := (p, t, uz). Note, that the currently used DS mask u, stems from the 


A rev,next 
previous wallet state rP"®V as u, = u 


. In preparation for the double-spending mechanism 
in the upcoming transaction, the user embeds a fresh DS mask uf! in the re-randomized 
version cy pa of the current updatable commitment (see above). 

The creation of the recalculation tag wrc is straightforward as the PoS has all necessary 
information at hand and can simply compile it. For details see Section 7.1.4. 

For the prove-participation tag cy and its hidden counterpart pp the user creates a com- 
mitment (ep, doky) — C2.Commit(crs2),,, skqj) on the user's key and sends Cok, to the PoS 
in the second message. The PoS replies with a corresponding signature oy, in message 3. 
After that the user knows all components and can set the hidden prove-participation tag as 
Yop = (KT, Opp» doky) and the prove-participation tag as @pp ‘= Cpkyr 
In order to show that everything has been computed honestly, the user sends a proof ras 


part of the second message. In particular, x shows that the user knows a signed wallet state 
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Upko, pk. , Sku TP") 


P(pk,, certp, skp, blo) 


parse (pk, pk. pk a 
pK, pks) ja pk, 


parse (sP'*", gP'*". x, À, aq, 


¿Prev ¿prev prev 
Capd > “upd > upd ? 


Yu ) ¿= zPprev 


ert" 


Cfi das, Og, DP 


parse (pk, ap, p" prev) .— _ certo 
g :— PRF(A, x) 
R 
sG 
uj E Z, 


(ipa dipa) <= CI. Commit(crs®,, 


(A, pprev y pex ,x)) 
Ug, Coors Cert p 
— 
parse (pkp dp, 05°) = certp 
if SIG.Vfy(pko", op", (pk, ap)) = 0 
return L 
parse(pk? s , pkp- pkp ) = pkp 
t := u,sky + u, mod p 
(pk, m» — C2.Commit(crsQ),,, ska) 


cert prev 


stmnt = (pk, Pko ap ; 


kp Capi b Me) 


EI A 
wit :— (x, A, sky, Uy, SP, Prev, gr, gl, 


pPrev u wo prev 7, 
pk gi »81 O8 > dy. dra > dipa dix» 


prev rev rev cert,prev 
pkp QUUM eg OD Op P O.) 


?"upd ? upd ? 
7 — P2.Prove(crs,ox, stmnt, wit) 
S’, T, PQ 0b, 
Chk ay Capa? É 


parse (pk, pk. pk e 
pK, pk’) = pk, 


ti. 
parse (pkp, dp, op") := certp 


parse a := pk, 
parse (sk¥P*, skis, skPP) := skp 


? 


(cd?) = C4.Commit(crsQ2,, s" 


Figure 7.18: The Core Protocol for Task Deposit, Part 1 (used by Fig. 7.16) 


149 


7 System Instantiation 


prev 
S’, T, Q, Ay, Ap > Cpk p Capd» É 
> 


return (OK) 


prev 


stmnt :— (pk? pk", Q, aqp ap, 
Cpkap Capd? tus) 
if P2.Vfy(crs 


polo SEmnt, zr) = 0 


return L 
if p € bl; 
return blacklisted wallet 


n 


S:= +8 


return (s, aq, ab^) 


Figure 7.19: The Core Protocol for Task Deposit, Part 1 (cont., used by Fig. 7.16) 


uQ 


s", d” 
< 


Pp) 

(esa Aupa) = C1.Commit(crs(?,, 
(0, p,0,1)) 

Cupa 77 Cry" Capa 

Supa = SIG.Sign(skz?", (Capa, s) 

T + SIG.Sign(skz, (s, o, g?)) 


Opp — SIG.Sign(skp’, cy.) 


n" 
ser? Cupd> d upd p> Opp 


if C4.Open(crs on, s", cz... des) = 0 


return L 

if SIG. Vfy(pK?, Opp» Cpky) = 0 
return L 

S:— s.s" 

dupa = dipa ` da 

pipe + p 


next = x + 1 

TS (s, Q, Xm A, ay, Capd» dupa> Üupd: 
Certo, Cix dex Oix D, un) 

Yop = (bk Opp» d, ) 

Opp = Choka 


return (T, Opp» Yoo) 


Oas = (Q, t, Up) 
Vic = (5,9, p, pkp» Ore) 
Wye = ENC2.Enc(pko"", Wee) 


Opp `= Cok, 


return (Was Orc Opp) 


Figure 7.20: The Core Protocol for Task Deposit, Part 2 (used by Fig. 7.17) 
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involving commitments cg, and cP"*” such that cP" and c/.., are commitments on the same 
upd upd upd 
messages except for the DS mask, that the (hidden) signature on cP od verifies under some 


(hidden) PoS key pk” certified by the b A and that t, g, and c pk, have been computed 


using the values contained in cg, and Cip 4 - Formally, the language i ) of the statement stmnt 


for the proof zr is defined by 


3x, À, skqy, uy € Zy; 
sPFEV, gPI®Y, X, A, pk, BP" U, UPO, dog A Kpa dx € Gi; 
PREY = (pkYPAPIEY, propre c (G3 x Gp) x (G2 x G3) 
p x T pd * Cox € Ga; 
p Ci.Open(crs UJ). o lE =1 
ay C2. Open(erstm ple Cok? dy. )=1 
D = ap C1. Open(ers()),,, (A, BPrev U,. X), nd did) = =1 
“pkay Ci Open(ersC2),, (A, BE UEM X), C, pd? dipa) = 1 
Capd SIC. Vfy(pkD*, ag. (aa) = 1 
] SIG. VIA P o EY, (Pn ghee 
Uz SIG.Vfy( pk oj prev ( phere’, ade) = 
gPrev = PRF(A, x — 1), p = PRF(A, x), 
t = Uugskqy + Uy 
pky = gU =g", X = gt, A= gl 


(7.13) 

As a minor detail, the parties mutually exchange various “administrative” information which 

is check for validity. The PoS sends its certificate certo as part of the first message to show that 
it is a valid member of the system or the user aborts before responding to the DS challenge. 
Vice versa, the PoS aborts after the second message, if the user turns out to be blacklisted due 


to the fraud-detection ID ọ being listed in blg. 


7.3.3 Disbursement 


The task Disburse (cp. Figs. 7.21 and 7.22) complements the task Deposit and is executed 
between a user and operator to disburse all points on a wallet which have been deposited 
before. As detailed out in the system definition (cp. Section 4.3.3) the given instantiation is 
tailored to the post-payment scenario from Section 2.3.3. 

Unsurprisingly, the implementation of Disburse is very similar to Deposit and actually 


simpler: both parties are identified and thus certain checks of validity do not require a ZK 
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UC-Protocol zp;c (cont.) - Task Disburse 


User input: (disburse, sP'*V) 
(1) At the user side: 
(a) Load the internally recorded (pk, ;, skq).- 
b) Receive pk, from the bulletin-board 7,, for PID pid... 
PKo bb play 
(c) Load the internally recorded token TP“ for serial number sP!*V + 
d) Call Fs. with (establish-session, ident, pid, disburse). 
msg pido 
2 t the operator side upon receiving (establishing-session, ssid, pid,,, disburse 
At the op ide up iving ( d, pid,, 
from fq: 
(a) Load the internally recorded (pko, sko).^ 
eceive rom the bulletin-boar or id, ,. 
b) Receive pk, fi he bulletin-board Fpp f PID pid, .- 
Operator output: (disbursing, pid.) 
Operator input: (disbursing) 
3 t the operator side: Ca with (accept, ssid ). 
At the op ide: Call Fnsg with ( d) 
(4) At the user side: Receive (accepted, ssid) from msg: 


(5) Both sides: Run the code of Disburse between the user and the PoS (see Fig. 7.22) 
using (send, ssid, ...) of Finsg for messaging: 


(pit, (pbill Ods 29) < Disburse (U(pko, pkay Skqy TP), O(pko, pk). 


(6) At the user side: Call Fnsg with (close, ssid). 
(7) At the operator side: Receive (closed, ssid) from Finsg. 


User output: (disbursed, bbill) 
Operator output: (disbursed, bbill, wgs, wre) 


1 Tf this does not exist, abort. 


Figure 7.21: The Protocol psc (cont. from Fig. 7.1) - Task Disburse 


proof, the price equals the previous balance and thus no additional input is required which 


allows the protocol to be non-interactive, no new serial number needs to negotiated as the 


wallet is destroyed and no prove-participation tag is necessary. Accordingly, the objectives of 


Disburse are a subset of the objectives of Deposit: 
(1) Unveil the price p := DP'** to the operator. 


(2) Generating (a) a double-spending tag wg, and (b) a recalculation tag c. 


We refer the reader to the previous section on Disburse for a description. Please note, that the 


second message still contains a ZK-proof 7, because the updatable commitment Cp which 
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U(pko, pk sky, pv) 


O(pk,, pk, ) 


parse (pk, po ae. 
pk ‚sig pk’ enc) .— - pk, 


parse (sP'**, pP! x, A, aqp, 


Prev ¿prev prev prev 
Cupd > und ? umm „ce rip 


Cüx: dix Ofixo prex > ui) M 
prev ab cert,prev) ,__ prev 
parse (pk Op ) = cert 


py := PRF(A, x) 


t := uysky + u, mod p 


pprev 
lus) 


ji A 
wit :— (x, A, skqy, Uy, SY, prev, gr. gl, 


gi rev prev rev 
t, dR’, dg, PREY, PY, Coe 


stmnt = (pk, pe. pko”, o, gi 


8 > upd ? 
prev | cert,prev prev 
Supa > p Op) 


m < P3.Prove(crs,,, stmnt, wit) 


pbi ¿= bprev 


return (pi!) 


u, 


TO, pprev t 


OK 


parse (pk, DK, pro”, 
pk „sig pke enc) .— = pk, 


cert pprev 


stmnt := (pk, pro, pko e.g tu) 
if P3.Vfy(crs,.,, stmnt, 7) = 0 


return L 


pbill .— pprev 

sG, 

Ore + SIG.Sign(sko^*, (s, p, gr) 
as = (Qt, Up) 

Yoo = (S, P, Ps Pk, Fe) 

De E ENC2.Enc(pk5^*, Wee) 


return (b>! Ogs, Wye) 


Figure 7.22: The Core Protocol for Task Disburse (used by Fig. 7.21) 
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contains the previous balance DP'*" is only unveiled indirectly in order to assert unlinkability 
to the previous transaction. More precisely, P3 is used to compute a proof z for a statement 


stmnt from the language D defined by 


3 x, À, skqz u1 € Zy; 
sprev. gY, X, A, Ui dis, de, € Gr; 
pir 2 (pkupdprev, ps prev) e (G3 x Gy) x (G2 T G3) 


ju 
"Eu Capd + ix € G2; 
re cert,pre 
Phu || Cute > Six € 02 X Gi; 
pko a Gh, db) prev e Gy. 
„cert u 1 
O 
19) » C1. Openers (A PK) ix» Ux) = 1 (7.14) 
Bprev Ci. Open(crs (ohn. (A, BPE, Uy, X), Ad: dipa) = zu 
t SIG. Vfy(pkb* Og (Ca) = 1 
N SIG, Vfy (pk oP = 


SIG. Vfy(pko ‚op cert,prev Aa a de 
pPtev = PRF(A,x — 1), = PRF(A, x), 
t= ugskqy + uy 

k 
pky=gi 5, Ui = gy, X= at, A= gt 


The proof is a simplified version of the one in the Deposit protocol. The balance DP'*Y and the 
public user key pk, are now in the statement and not in the witness and nothing needs to be 


, 
proven about Capd and Cok 


7.4 Utility Tasks 


7.41 Double-Spending Detection and Guilt Verification 


The double-spending tag wg, generated by the PoSes are periodically transmitted to the op- 
erator's database which is regularly checked for two double-spending tags c, = (Q,t, uz), 
QA, = (p”,t”,uz) which are associated to the same fraud-detection ID y = q”. If the database 
contains two such tags, the operator can use the task DetectDS (see Fig. 7.23) to extract the PID 
pid,, of the user to which these double-spending tags belong as well as a proof x that the user 
is guilty. For an explanation of the double-spending detection mechanism see Section 7.1.4. At 
the bottom line, two double-spending tags with the same fraud-detection ID denote two points 
on the same line whose slope is the secret key skq, of a user. The secret key does not only 
establish the fraudster's identity but also serves as the proof of guilt. Any party can run the 


task VerifyGuilt (cp. Fig. 7.24) to check the validity of a pair (pid, ,, 7). The task is implemented 
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UC-Protocol zp;c (cont.) - Task DetectDS 


Operator input: (detect_ds, wg.,@4,) 
(1) Parse (¢,t, ug) := wg, and (p”,t”, u) := Whg 
(2) If 9 + y” or uz = uz, output (pida, = 1, = L) to operator and terminate. 
(3) skar = (t — t)/ (uz — us) mod p. 
k 
(4) pku = = 
5) Receive pid, , from the bulletin-board Fpp for pk, y; if pid,, = L, set m := L, else 
play bb for pKay U plaqy 
T:= sku. 
Operator output: (detected ds, pid, , 1) 


Figure 7.23: The Protocol psc (cont. from Fig. 7.1) - Task DetectDS 


UC-Protocol zpsc (cont.) - Task VerifyGuilt 
Party input: (verify guilt, pid, 7r) 
(1) Receive pk, from the bulletin-board Fpp for PID pid, or set pk, = L if no pid, is 
registered. 
(2) If g= Pkap then result :— OK, else result := NOK. 


Party output: (verified_guilt, result) 


Figure 7.24: The Protocol mpsc (cont. from Fig. 7.1) - Task VerifyGuilt 


as local algorithm as the check gf = pk, is all what is needed. For honest users who kept their 
secret key securely away protection against false accusation follows from the hardness of the 
DLOG. 


7.4. Wallet Blacklisting 


The task BlacklistWallet (cp. Figs. 7.25 and 7.26) executed between the dispute resolver and 
operator is used to recover the sequence blg, of fraud-detection IDs of a wallet and thereby 
allows blacklisting. The implementation is apparent as the blacklisting tag cj is an encryption 
under the public key of the dispute resolver (cp. Section 7.1.4). Remember that we assume 
that the dispute resolver and operator agreed out-of-band what user is going to be blacklisted. 
After the dispute resolver has decrypted «yy it first checks, if the decrypted user key pk, equals 
the expected key pk. Together with the CCA-security of the encryption scheme this rules 
out malleability attacks which might try to trick the dispute resolver to recover the fraud- 


detection IDs of different (possibly innocent) user than assumed. After that the dispute resolver 
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UC-Protocol zp;c (cont.) - Task BlacklistWallet 


Operator input: (blacklist_wallet, (y) 
(1) At the operator side: 
(a) If foi, (cj) is undefined, output (blacklisted_wallet, Ø) to operator and halt. 
A 


(b) Call msg with (establish-session, ident, pid pp, blacklist wallet). 


DR? 
(2) At the dispute resolver side: Receive (establishing-session, ssid, pido, 
blacklist wallet) from Finsp. 


Dispute resolver output: (blacklisting wallet) 
Dispute resolver input: (blacklisting wallet, pid, /) 


(3) At the dispute resolver side: 
(a) Load the internally recorded (pk yp, Skpr).* 
(b) Receive pk from the bulletin-board Fpp for PID pid, 
(c) Call 75,4 with (accept, ssid). 
(4) At the operator side: Receive (accepted, ssid) from Fmsg- 
(5) Both sides: Run the code of BlacklistWallet between the dispute resolver and the 
operator (see Fig. 7.26) using (send, ssid, ...) of Fnsg for messaging: 


((0k), (blp,)) — BlacklistWallet (DR(pk pp, sk pg, Pky), (py) - 


(6) At the operator side: 
(a) Redefine fola ov = blg,. 
(b) Call Fnsg with (close, ssid). 
(7) At the dispute resolver side: Receive (closed, ssid) from msg: 


Dispute resolver output: (blacklisted wallet) 
Operator output: (blacklisted wallet, blg,) 


+ If this does not exist, abort. 


Figure 7.25: The Protocol psc (cont. from Fig. 7.1) - Task BlacklistWallet 
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DR(pK pp Skpp; Pk.) Op) 


bly, =D 


parse (A”, Y) = @yı 
(Ag, <- , Ata A”, pk) = ENC1.Dec(skpr, Yi) 


if decryption suceeds ^ A” = gå” ^ Pky pk, 
ti r 
li= Ar + >. DLOG(A‘) - B 
bly, = {PRF(A, 0), ..., PRF(A, Xpouna)} 


ble, 


return (0K) return (bly,) 


Figure 7.26: The Core Protocol for Task BlacklistWallet (used by Fig. 7.25) 


reconstructs the wallet ID A from its chunks and evaluates the PRF (x,ounq + 1) times. Since 
each of the chunks Aj is small (A/ < B), the dispute resolver can compute the discrete logarithms 
of (A/ in a reasonable amount of time. This algorithm is also not time-critical and is expected 
to be executed only a few times. At the end, the operator internally redefines foto, (yj) = bla, 
with the receives blacklist blg, to mark the blacklisting tag «yj as blacklisted. 


A tempting but insecure alternative Skipping ahead to the security proof, we would like 
to point out an alternative implementation. At first glance, it seems to be sufficient, if the 
dispute resolver decrypts the blacklisting tag cj, only checks if the expected user key has been 
decrypted and then sends back the decrypted cleartext y; to the operator, but leaves the rest 
of the work to the operator. This seems tempting, because it minimizes the computational 
work for the trusted third party (the dispute resolver) and puts the operator is in charge of 
computing the DLOGs and evaluating the PRF. However, this shift of the work load let the 
security proof fail. The operator must not learn the (secret) wallet ID A even for blacklisted 
users. The crux of the matter is that for honest users, who might also become blacklisted, the 
pseudo-random fraud-detection IDs are replaced by truly random numbers in the security 
proof as it is also the case in the ideal model to argue unlinkability. If the operator is corrupted, 
this would require to come up with a wallet ID A that explains a sequence of truly random 
numbers, which have been output by previous transaction, as the image of the PRF. Hence, it 
is admissible that the dispute resolver sends an evaluated sequence of the PRF to the operator, 


but disclosure of the seed is unacceptable. Actually, for the same reason the security proof fails 
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UC-Protocol zp;c (cont.) - Task RecalculateBalance 


Operator input: (recalculate_balance, blg, 2,.) 
(1) Load the internally recorded (pkg, sky). 
(2) Run bhil E RecalculateBalance(pko, sko, blo, Qc) (see Fig. 7.28). 


Operator output: (recalculated balance, bPill) 


1 Tf this does not exist, abort. 


Figure 7.27: The Protocol psc (cont. from Fig. 7.1) - Task RecalculateBalance 


RecalculateBalance(pko, sko, blo, Pre) 


parse (pk, pk. pir. po pk5^) = pk, 

parse (D s", Sk, sks, sk) = sko 

V. = {the — ENC2.Dec(sk5 5,0.) | Ope € Qe} 

PH == fs, o, p, pkp» Ore) € Yre | SIG. Vfy(pkz. Oc, (5, Y, 81)) = 1] 
E = {(s,p) | A the = (5,9, p.) € Vit ng € ble} 

B= Y eb 


return (bil!) 


Figure 7.28: The Core Protocol for Task RecalculateBalance (used by Fig. 7.27) 


under adaptive corruption. Interestingly, the shift of work load from the dispute resolver to the 
operator which unveils the wallet ID A to the operator and turns out to be formally insecure 


does not seem to allow for any “real-world attack”: 


7.4.3 Balance Recalculation 


The task RecalculateBalance (cp. Figs. 7.27 and 7.28) complements wallet blacklisting and allows 
to match the set of collected recalculation tag (2,. with the set of fraud-detection IDs blg, of a 
blacklisted wallet and thereby re-calculate the true balance of a wallet while taking parallel 
wallet states due to double-spending into account. The implementation is straightforward: 
The operator decrypts the recalculation tags, verifies their validity, i.e. drops those which are 
invalid, and uses the remaining set to sum over the prices of those tags whose fraud-detection 


ID is contained in blg. 


* Atleast, we could not come up with one. 


158 


7.4 Utility Tasks 


As already discussed for the definition of the system RecalculateBalance only gives very 
weak guarantees (cp. Sections 4.4.3 and 5.4.2). However, here we would like to point out 
another detail that should trigger action in the “real world” out of the scope of the UC-model 
and thus cannot be appropriately described? by pseudo-code. The serial number s is assumed 
to uniquely identify a single transaction and only occur once. If the operator encounters the 
same serial number twice, this is a clear indicator that at least one PoS must be corrupted and 
RecalculateBalance should throw an exception. In practice, this event should lead to further 
investigations and actions. The operator should try to identify the corrupted PoS and exclude 


it from the network. 


Please note, that a corrupted PoS might invent recalculation tags for the same serial number, 
validly sign them and send them to the operator. Those duplicates do not even need to belong 


to transactions that have taken place in the physical world‘ 


7.4.4 Prove of Participation 


The task ProveParticipation (cp. Fig. 7.29) is used by users to prove to the violation enforcer that 
they participated in a specific Deposit transaction with a PoS. To this end, the violation enforcer 
has been triggered by the PoS to physically identify the offending user, e.g. by taking a photo. 
Remember, this task is probably only a required in specific scenarios such as post-payment 
scenarios in that users are not physically prevented from gaining whatever benefit the system 
offers without paying first (cp. Section 2.3.3). Moreover, due to physical limits it might be 
impossible to exactly identify a single user, but accidentally suspicious several users of which 
all but one are innocent. The structure of prove-participation tags is described in Section 7.1.4 
and the implementation of ProveParticipation is straightforward. The presumingly guilty user 
is challenged on a set of prove-participation tags Q p which are connected to the offending 
incident in a timely and spatial manner and which must be provided by the same PoS which 
triggered the physical identification. The suspected user then may pick one of the proposed 
tags and unveil it. The binding property of the commitment underlying «y, asserts that only 


the legitimate owner can do so successfully and also only for the associated transaction. 


° Of course, there are options to extend the expressiveness of what can be described by pseudo-code. For example, 


introduce a new ideal functionality that provides a “handle” to the physical world and is used as a black-box. But 
this seems to be much of an overkill for a rather trivial issue. 

Note that part of the solution for the other issues is to also make the user sign the recalculation tags. This 
mitigates the problem, but does not entirely solve it. Still the environment could invent an user and corrupt it. 
The solution only prevents to create valid recalculation tags in cooperation with honest users. 
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UC-Protocol zp;c (cont.) - Task ProveParticipation 


Violation enforcer input: (prove participation, pid, pid, Qpp) 

(1) At the violation enforcer side: 
(a) Receive pk, and pk, from the bulletin-board Fpp for PID pid, and pidp.+ 
(b) Parse pk from pkp. 
c) Ca with input (establish-session, ident, pid,,, prove participation). 

Call Fs with input ( blish ion, ident, pid, icipatión) 
(2) At the user side upon receiving output (establishing-session, ssid, pid yp, 
prove_participation) from Fnsg call msg with input (accept, ssid). 


(3) At the violation enforcer side upon receiving output (accepted, ssid) from Fnsg, call 
Fmsg With input (send, ssid, (pid p, Qyp)). 


(4) At the user side receive output (sent, ssid, (pidp,Qpp)) from Finsg- 
User output: (proving participation, pid,,, pp) 
User input: (proving_participation, Opp) 
(5) At the user side: 
(a) Set Ypp = fpp(pp)-" 
(b) Call Fmsg with input (send, ssid, (@pp, Ypp))- 


(6) At the violation enforcer side upon receiving output (sent, ssid, (@pp, Ypp)) from 
os 


(a) Set Cpk,, = Opp 
(b) Parse (^, Opp» dp.) = op. 
(c) If py € Qpp and C2 0pen(crsQ),, pkap Cpk, doky) =1and 
SIG. Vfy(pKTP, opp, Cok, = 1, then result := OK, else result := NOK. 
(d) Call Fmsg with input (close, ssid). 
User output: (proved_participation) 


Violation enforcer output: (proved_participation, result) 


+ If this does not exist, abort. 


* Nb, Yop = L may hold, if fog (opp) is undefined. 


Figure 7.29: The Protocol psc (cont. from Fig. 7.1) - Task ProveParticipation 
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VerifyWallet(pko, pk, ,, T) 


cert upd rc,sig rene , 


fix 
parse (pko pkg Pko Pko ~» Pko = pko 
parse (s, p, x", À, day, Cupa» dapa» Oupa» CCT Lp, Cs dixs Ofix D, Up") = T 
parse (pk,,, dp, 05°) = certp 
upd re 
parse (pkp ,Pkp) = pkp 
if 
C1.Open(crs)),, (gi, pk,)), Cg dg.) = OV 
SIG. Vfy(pk^*, Ofixo (Caxs Ay) = OV 


unext 


C1.Open(crs),,, (gi, g?, gy " ad Capd» dapa) =0v 
SIG. Vfy(pk"", apa» (Cupa S)) = OV 
SIG.Vfy(pk5 08°", (pkp, ap)) = 0 v 
PRF(A, x — 1) # 9 
then return 0 


else return 1 


Figure 7.30: Helper Algorithm VerifyWallet 


7.4.5 Wallet Verification 


The algorithm VerifyWallet (cp. Fig. 7.30) is not a task by itself, but only a helper algorithm 
that is used inside of IssueWallet and Deposit (cp. Figs. 7.13, 7.16 and 7.17). A user can verify 
with this algorithm that the wallet he stores at the end of a transaction is valid. In particular, 
the algorithm verifies that the commitments cg, and ¢,,4 are valid and contain the values they 
are supposed to contain, that og, is a valid signature under skBr of cg, and aqy, that oupa is a 
valid signature under skp of cp q and s, that the certificate certp containing pk; is valid and 


that the fraud-detection ID 9 was calculated using the correct values. 
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8 Security Theorem and Proof 


In this chapter we show that zypsc UC-realizes fpc in the (Fors, Fpp)-hybrid model for static 


corruption. More precisely, we show the following theorem: 


Theorem 8.1 (Security Statement) Assume that the SXDH-problem is hard for gp := (G4, Ga, 
Gr. e, p, 81, £2), the X%,ounq-DDHI problem is hard for G,, the DLOG-problem is hard for G, and 
our building blocks (NIZK, commitment schemes, signature scheme, encryption schemes and PRF) 


are instantiated as described in Section 6.2. Then 


Fers-F wb. ms 
Tpsc € 2uc Fape (8.1) 


holds under static corruption of either 


(1) a subset of users, 
(2) all users and a subset of PoSes, operator and violation enforcer, 
(3) a subset of PoSes, operator and violation enforcer, or 
(4) all PoSes, operator and violation enforcer as well as a subset of users. 
Pnoor Follows from Theorems 8.2 and 8.28. = 


Informally, this means the ideal model and our protocol are indistinguishable and therefore 
provide the same guarantees regarding security and privacy. Please note that the hardness of 
the DLOG-problem is already implied by the SXDH-assumption. 

This chapter is organized as follows. In Section 8.1 we discuss the corruption model, especially 
the restrictions on the set of corrupted parties and why this limited corruption model seems 
not to be a severe restriction from a practical vantage point. In Section 8.2 we give a brief 


outline of the proof on a high level. The actual proof for Theorem 8.1 is given in two parts: 


* In Section 8.3, Theorem 8.2 proves Theorem 8.1 for the corruption scenario (1) and (2). 


We call this case “Operator Security”. 


* In Section 8.4, Theorem 8.28 proves Theorem 8.1 for the corruption scenario (3) and (4). 


We call this case “User Security and Privacy”. 


Both sections follow the usual approach and prove the statement in a sequence of hybrids. 
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81 Adversarial Model 


Firstly, we only consider security under static corruption. This is a technical necessity to 
enable the use of PRFs to generate fraud-detection IDs. With adaptive corruption the simulator 
would be required to come up with a consistent seed for the PRF that could explain the up to 
the point of corruption uniformly and randomly drawn fraud-detection IDs. We deem static 
corruption to provide a sufficient level of security as a statically corrupted party may always 
decide to interact honestly first and then deviate from the protocol later (cp. Definition 3.14 
and the discussion thereafter). Adaptive corruption is tightly related to deniability which is not 
part of our desired properties. Instead, features like blacklisting, prove-of-participation and 
balance recalculation are quite contrary to deniability. Obviously, traceability of blacklisted 
users requires that users are indisputable bound to their past transactions. 

Of course, there might be valid applications that do not require these features but demand de- 
niability. In these cases, the tasks BlacklistWallet, RecalculateBalance and ProveParticipation 
could be removed from the system. This would allow to use a truly uniform random distri- 
bution instead of a PRF for the fraud-detection IDs and the encryption for the key escrow 
mechanism could be dropped, too. A close look at the security proof unveils that it holds 
under adaptive corruption after these modifications. In [Nag+17] the BBA+-scheme, which 
does not include these features, is shown to provide a security feature which is called backward- 
and forward-privacy. Although adaptive security and backward- and forward-privacy are not 
directly comparable due to formal reasons, the latter is even stronger than adaptive security 
on an informal level as it guarantees users to be unlinkable in future transactions even after a 
corruption. 

Secondly, we separately consider operator security and user security which means that Z 
is only allowed to corrupt certain restricted sets of parties (cp. Theorem 8.1). For operator 
security either (1) a subset! of users or (2) all users and a subset of PoSes, operator and violation 
enforcer is allowed to be corrupted. For user security and privacy either (3) a subset of PoSes, 
operator and violation enforcer or (4) all of PoSes, operator and violation enforcer as well as a 
subset of users might be corrupted. It is best to picture the cases inversely: To prove operator 
security we consider a scenario in which at least some parties at the operator's side remain 
honest; to prove user security we consider a scenario in which at least some users remain 
honest. Please note that both scenarios also commonly cover the case in which all parties are 
corrupted. However, this extreme case is tedious as it is trivially simulatable. 

One might believe that the combination of all cases above should already be sufficient to 


guarantee privacy, security and correctness under arbitrary corruption. For example, case (4) 


1 


Note that "subset" also includes the empty or full set. 
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guarantees that privacy and correctness of accounting are still provided for honest users, even 
if all of the operator's side and some fellow users are corrupted. This ought to be the worst case 
from an honest user's perspective. Further note that the proof of indistinguishability quantifies 
over all environments Z. This includes environments that—still in case (4)—first corrupt all 
the operator's side but then let some (formally corrupted) parties follow the protocol honestly. 

From a technical point the crux are the ZK proofs which either can be extracted or simulated 
but not both in the same experiment for different transactions involving an honest user and a 
corrupted PoS in one transaction and vice versa a corrupted user and an honest PoS in another 
transaction. Note, that this problem vanishes in the cases (2) and (4), because in these cases all 
parties belonging to one side are completely corrupted and interactions with corrupted parties 
of the other side are trivially simulatable. This suggests as if the truly mixed case should fail due 
to some sort of malleability attack involving honest users at one side, a man-in-the-middle, who 
cobbles ZK proofs, and honest PoSes at the other side. One might expect to find an adversary 
who merges an ensemble of wallets in a way such that the resulting wallet states cannot be 
mapped in the ideal model. However, we were not able to construct such an adversary. Even 
more interestingly, as explained in Chapter 10 using a non-shrinking commitment scheme in 
exchange for less efficiency allows to waive extractable ZK proofs and thus enables a proof 
under arbitrary corruption. One would expect that this observation should help to “spot the 
weak point". All in all, it seems that the proof of indistinguishability (for our proposed, efficient 
implementation with shrinking commitments) under arbitrary corruption only fails due to a 


formal problem but does not allow for a “practical” attack in the real world. 


8.2 Proof Outline 


As mentioned above we separately prove operator security with respect to an environment 

Z?P5** as well as user security and privacy with respect to an environment ZUS@""se©, Both 
Op-sec user-sec : 

"bs: and SC , resp., for the ideal 

N ñ ü : 

experiments EXEC psc, sopas zopsee( ); EXEC msc, Suerse, zusersec( 1"), resp. For each scenario we 


proofs are conducted by explicitly specifying a simulator S 


define a sequence of hybrid experiments H; together with simulators S; and protocols zr. Each 
hybrid is of the form 
H; = EXEC, s z(1”). (8.2) 


The first hybrid is identical to the real experiment and the last hybrid is identical to the ideal 
experiment. The general idea is that the protocol z; for honest parties gradually declines 
from the real protocol 2p = psc to a dummy protocol, which does nothing but relay in- and 
outputs. At the same time S; progresses from a dummy adversary S, = D to the final simulator, 


which can be split up into the ideal functionality Fapc and Sma or Sy. see, resp. Instead 
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of directly proving indistinguishability of the real and ideal experiment we can break the 
proof down into showing indistinguishability of each pair of consecutive hybrids. We achieve 
this by demonstrating that whenever ZP“ or ZUS*S€C, resp., can distinguish between two 
consecutive hybrids with non-negligible probability this yields an efficient adversary against 
one of the underlying cryptographic assumptions. The indistinguishability between the real 


and ideal experiment follows from the pairwise indistinguishable of consecutive hybrids. 
op-sec 
Apsc 

a good share of common code, because some combinations of corrupted parties occur within 


The simulator for operator security S and the simulator for user security Sapo °°° have 
particular tasks for both settings. This is unsurprising if one considers that not much seems to 
lack for an arbitrary corruption setting. The shared code for the common part is presented in 
both simulators. Naturally, this causes redundancy, but this way each simulator is complete 
and we avoid a lot of confusing references. However, the hybrids H; which transfer the real 
experiment into the ideal experiment are only presented once. They are only defined and 
proven for operator security (cp. Section 8.3) and re-used for user security (cp. Section 8.4). 
However, there are still segments within the sequence of hybrids that differ between operator 
security and user security. 

For the proof of operator security (cp. Section 8.3) input privacy does not pose any problem. 
The user learns nearly everything about the operator as part of its prescribed output and thus 


simulation of mostly all messages is perfectly enabled. The crucial point is to prove that no user 
Op-sec 
Apsc 

the extraction property of the zero-knowledge scheme to watch messages from the corrupted 


can deviate from the protocol and thereby cheat the operator. To this end, S basically uses 


users for discrepancies. 

Contrarily, the proof of user security (cp. Section 8.4) follows a different spirit. In this case, 
input privacy of the user is the crucial point. For these reasons, most hybrids replace messages 
from the user by information-theoretically “empty” messages that are independent from any 


user secret. 


8.3 Proof of Operator Security 


In this section we show the following theorem. 
Theorem 8.2 (Operator Security) Under the assumptions of Theorem 8.1 


Fors F ob-Fn 
Tpsc =e 2uc Fape (8.3) 


holds under static corruption of 


(1) a subset of users, or 
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(2) all users and a subset of PoSes, operator and violation enforcer. 


The definition of the UC-simulator SE. for Theorem 8.2 can be found in Figs. 8.2 to 8.18. 


Please note that while the real protocol psc lives in the (Fors, Fb Fmsg)-model the ideal 
functionality 755. has no CRS. The CRS simulated by STS" giving it a lever to extract the ZK 


"ipsc 
proofs P1, P2, and P3 and to equivocate the commitments C2 and C4. 
op-sec 
"ipsc 
what the parties or the ideal functionality internally record, namely the map of simulated prove- 


While the protocol executes, the simulator S records certain information similar to 


participation tags dis and the simulated transaction graph TRDB. Basically, top and TRDB 
correspond to fpp and TRDB resp., but exist in the head of the simulator and are augmented by 
additional information. The simulator uses them as “lookup tables” to keep up a consistent 
simulation in later parts of the protocol. Obviously, this implies that information is stored 
redundantly: In the head of SP.“ as Jop and TRDB and inside the ideal functionality Tape (in 


Apsc 
case of TRDB) or the environment (in case of fy, for a corrupted user). A crucial part of the 


security proof is to show that these sets stay in sync. 
Before starting with the security proof, we explain the Simulated Transaction Graph TRDB. 


This Simulated Transaction Graph resembles the Ideal Transaction Graph (cp. Definition 5.1) 
but augments each node by the in- and out-commitments (c, = e ) and Cet cout) from the 


real protocols. A Simulated Transaction Entry trdb has the form 


trdb = (sPrev, s, Q, x, À, pid q, pidp, p.b, 


up, Ods» Orc» Opp; (8.5) 

: . "C : : 8.5 
in 1n in in in in 

Chie? Piso Mio Capd’ did M pd? 


out Jout „out „out gout out 
Chie ie Mix” Cupa’ dapa Mind 


with c, d and m with equal suffixes denoting a commitment, its decommitment information and 
the opening in the implicit message space (see Fig. 8.1). These commitments are the fixed and 
updatable part of the wallet before and after the transaction (cp. Chapter 7). At the beginning of 


a transaction in the scope of Deposit or Disburse the user loads his token 7P!*" which contains 


rev 
cP 


upd ° randomizes the commitments and at the end the user possesses 


two commitments cg, and 


; 5, Q9, x, A, pid, , b 
dd pen pidp, D» Ods» Ores Opp PS S Pilip m 
UU in in in out out out next ix 
Cio dix Mix» Cx» dax Is U) 
i i i t t t 
Capa? dipa’ Mapa Capd dapa Mapd 


Figure 8.1: An entry trdb € TRDB visualized as an element of a directed graph 
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op-sec 


Simulator Sy... 


Setup: (1) Run a modified version of the algorithm crs — Setup(1”) with 


(a) ers), < C2.Setup being replaced by (ers), tdeqcom) €- C2.SetupSim, 


(b) ers), < C4.Setup being replaced by (ers, tdeqcom)  C4.SetupSim, 
and 
(c) crsyg, - POK.Setup being replaced by (crspoy, depor) = POK.SetupExt. 
(2) Record crs, tdegcom and td 
(3) Set TRDB := Q. 
(4) Set Ties : PID — {0, 1}* to the “empty” map. 


epok: 


(5) Set Jop : Opp > Ypp x {0, 1}* to the “empty” map. 


Op-sec 
IPSC 


The internal copy of Fmsg: S 
proceeds as follows: 


runs an internal instance of 75, in its head and 


(1) Upon receiving input of the form (establish-session,...), (accept, ...), 
(send, ...) or (close,...) from Z?P^ ** for Finsg in the name of a corrupted party, 
Sr forwards this input to its internal instance of Fmsg in the name of the 
same party. 

(2) Upon receiving output of the form (establishing-session,...), (accepted, ... ), 
(sent, ...) or (closed,...) from its internal instance of Finsg for a corrupted 
party, Sb forwards this output to Z*P"*ec, 

(3) Upon receiving leakage from its internal copy instance of 75, for an 
adversary, Su forwards this leakage to Z?P'5*€ as the real dummy 
adversary would do. 

(4) Upon receiving output of the form (establishing-session,...), (accepted, ... ), 


(sent, ...) or (closed,...) from its internal instance of Finsg for an honest party, 


sop-sec 


msc handles this output internally as desribed below in detail. 


Figure 8.2: The Simulator for Operator Security 
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op-sec 


Simulator Sy... 


RegisterDR (for honest dispute resolver): Upon receiving leakage 
(registering dr, pid pp) from fap, and if keys (pid pp) is undefined, run 


(pk pp: skpg) — RegisterDR(crs), and append pid pg +> (pk pp» skpg) to p 


RegisterOp (for honest operator): Upon receiving leakage (registering op, pido, ao) 
from fapc and if freys(Pidg) is undefined, run 
(pko, sky, certo) — RegisterOp(crs, ag), and append pido > (pko, sky, certo) to 
p 


RegisterPOS (for honest PoS): Upon receiving leakage (registering pos, pid,,) from 
fap. and if keys (pid) is undefined, run (pkg, skp) — RegisterPOS(crs), and 
append pid, > (pkp, skp, L) to freys 

RegisterPOS (for corrupted PoS): Upon receiving input (register, pkp) from ZUSer-sec 
for 7 in the name of P with PID pid,, and if fkeys(pidp) is undefined, call Faye 
with input (register) in the name of P with PID pid,, ignore the subsequent leak 
(registering pos, pidp) from fpc and append pid, > (pkp, L, L) to fiy," 


RegisterUser (for honest user): Upon receiving leakage (registering user, pid,,) from 
fap, and if ficeys(Pidq)) is undefined, run (pk, ,, sky) — RegisterUser(crs), and 
append pida, > (Pkap skqj) to Mage 

RegisterUser (for corrupted user): Upon receiving input (register, pk,,) from Z°PS°° 
for yy in the name of U with PID pid,,, and if Áieys (pido) is undefined, call Faye 


with input (register) in the name of the same user, ignore the subsequent leak 
(registering user, pid,,) from Jape and append pid,, > (pk, L) to freys” 


* Corrupted PoSes essentially have two options: They can either register “some” public key at the bulletin 
board or not. (N.b., the public key does not need to be honestly generated.) If they register their public keys, 
then they are regarded as registered from the perspective of the real protocols. Hence, the simulator must 
also register the PoSes with Fipo, otherwise Fipe would subsequently abort, but the real protocols do not. 

> Corrupted users essentially have two options: They can either register a public key at the bulletin board or 
not. (N.b., the public key does not need to be honestly generated.) If they register their public keys, then 
they are regarded as registered from the perspective of the real protocols. Hence, the simulator must also 
register the user with 9,,., otherwise Fipe would subsequently abort, but the real protocols do not. 


Figure 8.3: The Simulator for Operator Security (cont. from Fig. 8.2) 
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op-sec 


Simulator Sy... 


CertifyPOS (for honest operator and honest PoS): Upon receiving leakage 
(certifying pos, pidp, ap) from Fape «+ 


(1) Set (pk, sko, certo) :— hreys(Pidg) and (pkp, skp, certh, ^) := keys (Pi) 

(2) Generate certp := (pkp, ap, og!) with og?! — SIG.Sign(skö" , (pk. ap)) 
faithfully. 

(3) Re-define hreys(Pidp) := (pkp, skp, certp) and let Fipe continue. 


CertifyPOS (for honest operator and corrupted PoS): (1) Upon receiving output 
(establishing-session, ssid, pid, certify_pos) from Fae for O, call Fape 
with input (certify_pos) in the name of P with pid,. 

(2) Upon receiving leakage (certifying_pos, pid, ap) from Fape ... 


(a) Set (pkg, sko, certo) := Fkeys(Pido) and (pkp, L, certh ™) = Fey Pip)? 
(b) Call rus with input (accept, ssid) in the name of O. 
(3) Upon being requested by ZUST"seC to provide the 1* message from O to  ... 


cert 


(a) Generate cert :— (pk, ap, og°") with oz?! — SIG.Sign(skg , (pkp, ap)) 
faithfully. 
(b) Redefine Ikeys(Pidp) := (pkp, L, certo). 
(c) Call ts with input (send, ssid, cert?) in the name of O for the 1* 
message from O to P. 
(4) Upon receiving output (closed, ssid) from E for O, let 9%). deliver its 
output to O. 
(5) Upon receiving output (certified pos, ap) from fpc for P, do nothing. 


^ N.b.: These assignments exist. An honest operator or honest PoS, resp., must have called RegisterOp and 
RegisterPOS previously, otherwise fp: would already have aborted. 

^ N.b: These assignments exist. An honest operator must have called RegisterOp otherwise %,, would already 
have aborted. The malicious PoS has either either registered its public key at the bulletin-board 7 or not. I£ it 
had not registered at the bulletin-board, then the real protocol would have aborted at the operator's side. The 
ideal functionality fpc would also have aborted and never leaked the message (certifying pos, pidy, ap) in 
the first place. Contrary, if PoS had registed at the bulletin-board, the real protocol does not abort. However, 
in this case Sz ^^ would have (silently) defined Tkeys(Pidp) and registered the PoS with Fip: and thus Fipe 
does not abort neither. 


Figure 8.4: The Simulator for Operator Security (cont. from Fig. 8.2) 
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op-sec 


msc (cont.) 


Simulator S 


IssueWallet (for honest operator and honest user): Upon receiving leakage 
(issuing wallet) from %,. and being asked to provide wy ... 


R 
(1) A” € Zy. (+2 
(2) Yp = ENC1.Enc(pk pp, (1, ..., 1)). 
(3) Set ap = A”, Jp). 
(4) Provide «y; to Fapc- 


Figure 8.5: The Simulator for Operator Security (cont. from Fig. 8.2) 


two updated commitments cg,, Cypa Which are stored in tagain. We call the initial commitments 


the in-commitments of the transaction and the resulting commitments the out-commitments. 


Definition 8.3 (Simulated Transaction Graph (informal)) The set TRDB = {trdb;} with 
trdb; defined as in Eq. (8.5) is called the Simulated Transaction Graph. It inherits the graph 
structure of the Ideal Transaction Graph and augments each edge by additional labels, called the 


in-commitments and out-commitments. 
Two remarks are in order: 


(1) Firstly, none of the (commitment, decommitment, message)-triples is neither completely 
received nor sent by the PoS or operator, respectively. The PoS receives a randomized 
version of the in-commitment and no decommitment at all. In the reverse direction, the 
PoS sends the out-commitment and a share of the decommitment. The complete triples 


only exist inside the user’s token. 


(2) Secondly, it is tempting but misleading to assume that cn d^ a a 


hold. Note that we do not make any of these assumptions for the definition. Hence, we 


(or similar equations) 


decided on a new notion and coined the term in-/out-commitments instead of re-using 
the term “previous commitment”. Actually, these kinds of equalities are what we have to 


show. 


The augmented information gives an alternative set of edges where two transactions trdb and 
— : : 

trdb are connected if (Copa? on) corresponds to (cap 25 Che ^y The hybrids which are specific to 
operator security introduce additional “sanity checks" on this alternative graph structure: if the 


sanity check holds, both transaction graphs are still in sync and the simulator proceeds; if the 


? N.b:: Commitments “correspond” if they are re-randomizations of each other, i.e. if they have the same message. 
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op-sec 


Simulator Sy. 


(cont.) 

IssueWallet (for honest operator and corrupted user): (1) Upon receiving output 
(establishing-session, ssid, pid, y, issue wallet) from Fn for O, call Tape 
with input (issue_wallet) in the name of U with pid, ;. 

(2) Upon receiving leakage (issuing wallet, s,aq,) from Fipe ... 
(a) Set (pkg, sko, cert y) = Freys(Pido) and (pk pp» skpg) := Feys(Pid pg)" 
(b) Call ud with input (accept, ssid) in the name of O. 

(3) Upon receiving output (sent, ssid, c? .,) from o for O ... 


(a) (chor dee) = C4.CommitSim(ers®,, 5 
(b) a” È Zp. 
c) Ca im with input (send, ssid, (cert, day, cl... in the name o Or 
Call Fmsg with input ( d, (certo, ay, Cser, A”)) in th fOf 
the 1* message from O to U. 
(4) Upon receiving output (sent, ssid, (s”, yy. cE, Cupd z)) from Fane for ©... 
(a) stmnt = (pkqp PK pp Vor Chix Capd aded a A"). 
(b) If PI.VfyCerspok stmnt, x) = 0, let Fape abort. 
(c) Extract Wit = (A, A’, At... Ad qs UP, do dung dhig SK q) = 
P1.Extract(crs poko tdepok: stmnt, 71). 
ssert that (stmnt, Wit) fu s the projected equations from and let 
d) Assert th Wit) fullfills the projected equations from LY) and 1 
Tape continue, else give up simulation (event EN). 
(5) Upon receiving leakage (issuing_wallet) from fpc and being asked to 
provide ¢... 
f-1 i 
(a) A=" + XL DLOG(AD - Bi 
(b) y := PRF(A, x) with x = 0 
(c) Provide ¢ to Fane. 


^ N.b: These assignments exist. An honest operator or honest dispute resolver, resp., must have called 
RegisterOp and RegisterDR previously, otherwise fp: would already have aborted. 


Figure 8.6: The Simulator for Operator Security (cont. from Fig. 8.2) 
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Simulator SP 5** 


mso cont.) 


IssueWallet (for honest operator and corrupted user, continued): (6) Upon receiving 

leakage (issuing wallet) from fpc and being asked to provide wp, ... 

(a) Set op = (47, y). 

(b) Provide cy; to Jape- 

(7) Upon receiving output (issued wallet, s, aqy) from aye for U... 

(a) s" := s.s 1 
(b) Equivoke dz, = C4.Equivoke(crsc),,, tdeqcom> s”, clh dzer). 
(c) og, — SIG.Sign(skÊ*, (cg, 244)) 
(d) Cand = SIG.Sign(sklP“, (Cupd» s)) 
( 


rev. x " in . in . 
e) Set sPI*Y := L, p := 0, b: 0, ce * Lan : 1, min = 1, Cid = L, 
dnd = 1, E = L, co = Crys d, = dig ment = = (A, pk. 
coed = Capel dop = dung and mil = = (A, gł, yest, get) 
(f) Append res, $, 9, X, À, pid, Ew b, ue > Ods» Vre» Opp: p. di, min, 
in in cout out mout cout gout mont 
“ipa pa ap upd’ Ex > dex máx > Cipa’ dapa "a a) to TRDB. 


(g) Call is; with input (sent, ssid, (s”, trat Supa)) i in the name of O for 
the 2"* message from O to U. 
(8) Upon receiving ouput (closed, ssid) from PY for O, let 745. deliver its output 
to O. 


Figure 8.7: The Simulator for Operator Security (cont. from Fig. 8.2) 
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op-sec 


Simulator S,,,. 


(cont.) 


Deposit (for honest PoS and honest user): (1) Upon reveiving leakage (depositing, 


pid„C,) from Tapes ... 
a) Set (pk, sku) := ficeys(Pidqy)." 


~ 


. R 
(b) Pick u E Zy. 
(c) Check if 3 QA. = (o^, t^, ug) € O s.t. e. #4 and uz + uz hold.” 
(d) If yes, t := t" + skqy(uz — uz). 


(e) Provide z := skq, to Fape- 
(2) Upon receiving leakage“ (depositing, s, p, pid) from fpc and being asked to 

provide (cs, Wrc Opp), --- 

(a) Set (pkg, L, 1) = hreys(Pidg) and (pkp, skp, certp) := hreys(Pidp).“ 
(b) Parse pko ™ from pko. 

(c) Parse pK sky from pkp/skp. 

(d) If (t, uz) is not yet defined, pick (t, uz) 2 Z2. 

y p p 

(e) Set wg, := (Q, t, uz). 

(f) Set Yc to an arbitrary value from the correct space.” 

(g) Set o, + ENC2.Enc(pk5 ^^^, Vic): 

(h) Run (ep, doky) — C2.CommitSim(ers2),, ] 

(i) Assign op, + SIG.Sign(sK7?, pku) 

: pem - pp q 

(j) Set Opp = pku and Yop = (pkp , Opp: doky) 

(k) Define Fop(@pp) = (pp. Er): 

(1) Provide (as c, pp) to Fape- 


N.b.: This assignment exists. An honest user must have called RegisterUser previously, otherwise Jape would 
already have aborted. 

N.b., even if the user commits double-spending no “useful”, previous double-spending tag may exist in [o 
if the user only did so at corrupted PoSes that undermine double-spending detection. 

Here, we only consider an honest operator. 

N.b.: These assignments exist. The operator/PoS must have called RegisterOp/RegisterPOS previously, 
otherwise 7,,. would already have aborted. 

Step 1d is only executed, if the user commits double-spending. 


^ The hidden recalculation tag is of the form Y. = (s, 9, p, Pkp» Ore) € Gy X G, x Z x (G? x G3) x (G2 x G,), e.g., 


Yre = (1, 1,0, 1, 1, 1, 1, 1, 1, 1, 1) would be a good choice. 
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Simulator So (cont.) 
Deposit (for honest PoS and corrupted user): 
(1) Upon receiving output (establishing-session, ssid, 1, deposit) from msg 


for P with pid,, ... 
(a) Set (pko, sko, certo) := fieys(Pidg) and (pkp, skp, certo) := hreys(Pidp); 
if these do not exist, let Ans abort. 
(b) Parse pkiP/ sh from pkp/skp and pk from pk». 
(c) Call md with input (accept, ssid) in the name of P with pid,,. 
(2) Upon being requested by Z°PS* to provide the 1* message from P to U ... 
R 
(a) Pick u, = Zy. 
(b) (c, die) — C4.CommitSim(crs(2 E 
(c) Call md with input (send, ssid, (us, Cay, certp)) in the name of P for the 
1* message from P to U. 
(3) Upon receiving output (sent, ssid, (s’, 2, 9, aq, ES. Cpk p Cipa t)) from Fon 
for P ... 
(a) stmnt := (DR, pke", Q, aqp, Un Cpk pd" t, uz). 
(b) If P2.Vfy(crSpoko stmnt, x) = 0, let nus abort. 
(c) Extract Wit = (X, A, pk, ,, Uj, sP*", gPT*V, X, A, pk, yo BPev, Lu LB. dy. : 
qprev d’ dg, pk" prev ne. Pee DEEV 0g) U 


upd > “upd’ > “upd ’ upd^ P 
< P2.Extract(crs „x, td stmnt, 7). 


d) Assert that (stmnt, Wit) fulfills the projected equations from 19g, else 
pro) q gp 
give up simulation (event El). 


(e) Lookup tab i= (SP 9% gt, y A*, pid, pido, p*,b*,Uf, a 
oe a ee "EE: * * * 
RoR" die" mit" cn d miss dg mit 
qu. qu. mou) with s* = sP'*Y being used as key; if no unique entry 
exists, give up simulation (event E2). 


pole "^epole 


out * + ¿Prev 
pd 


upd (event 


(f) Give up simulation if any of these conditions meet: c? 


E3), A + e (event E4), Qu * cg (event E5), pk,, + pku with 
(A*, pk; ) := mut” (event E6 , BPtev + gb" (event E7), X + gX +! (event 
Pu fix &1 £1 
E8), or U] + Ur (event E9). 
(g) Set pid; = freys Pkar ) 
(h) Call Apc with input (deposit, sP'*", pid,,) in the name of U with pid, . 


^ '[his assignment exist. Otherwise one of the previous tests would have already failed (cp. also proof). 


Figure 8.9: The Simulator for Operator Security (cont. from Fig. 8.2) 
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op-sec 


msc (cont.) 


Simulator S 


Deposit (for honest PoS and corrupted user, continued): (4) Upon receiving leakage 
(depositing, s, aq,) from fpc» let Fap. continue. 
(5) Upon reveiving leakage (depositing, pid, ,, QU) from Fape ... 
(a) Check if 3 w4, = (9’,t’, ug) € añ. s.t. us + uz and pkg, = giku for 
skqy += (t — t’) - (uz — u)! mod p holds.’ 
(b) If yes, re-define fi, (pid, ) = (pk, sku). 
(c) Provide x := skqy to Fape- 
(6) Upon receiving leakage (depositing) from fpc and being asked to provide 9, 
return g := PRF(A*, x) with x = x* + 1 to Faye.” 
(7) Upon receiving leakage (depositing, s, p) from fpc and being asked to 
provide (Ogs; Orc Opp), da 
(a) Set wgs = (o, t, uz). 
(b) Set Y, to an arbitrary value from the correct space.” 
(c) Set ye — ENC2.Enc(pk5 ^, Yc) 
(d) Assign op, + SIG.Sign(skbP, pk) 


(e) Set @pp = pku and Ypp = (pk, oy, dyk) 


(f) Define rl) = (Jp. pk). 
(g) Provide (cq. rc, Opp) tO Fape- 


* N.b. even if the user commits double-spending no “useful”, previous double-spending tag may exist in Ys 
if the user only did so at corrupted PoSes that undermine double-spending detection. 

” N.b.: Apc does not always ask for the next serial number. If the corrupted user re-uses an old token, then 
Tape internally picks the next serial number which has already been determined in some earlier interaction. 
Hence, the Se only needs to provide the next serial number, if the chain of transactions is extended. 

° The hidden recalculation tag is of the form y, = (8,9, p, pkp» Orc) € Gy x Gy x Zp x (G? x G2) x (G2 x Gy), e.g., 
Ye := (1,1,0,1, 1, 1, 1, 1, 1, 1, 1) would be a good choice. 


Figure 8.10: The Simulator for Operator Security (cont. from Fig. 8.2) 
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8.3 Proof of Operator Security 


op-sec 


Simulator Sy... 


(cont.) 


Deposit (for honest PoS and corrupted user, continued): (8) Upon receiving output 
(deposited, s, ap, p, b, yy) from Fape for U ... 
(a) Run (Cope? dipa) — Ci.Commit( ers). (0, p,0, 1), Capd = pd . Copa? and 
CT ae SIC.Sign sk? (Cupd» s)) honestly as the real protocol would do. 


(b) Set s" := s- s^! and equivocate dz, — C4.Equivoke(crs(4),,, 8”, cl, der). 


in .— in .— in ,— in ,— „PfeV sin .— prev 
(c) Set cm :— cay, den = dg, mp = (A, pka, aqu: dupd = d pd j 


in. .— prev out .— out .— qv . d" out .— 
Mind i (4, B ý Us, X), Cx Chix» dex dex dee Mey (A, pka), 


out ._ out . I . g” out ._ b rrnext. 4x41 
Cupd ‘= Cupd: dapd po d od dipa and Mind = (A, gj, Ui 81 ) 


f . l bo i, un 
(d) Append (sPF°Y, s, p, x, A, pid, pidp, p, b,UP™, Ods, Ores Opps Che Urs Mf 
in in in out Jout ,,0ut „out yout ,,out TRNR 
Capd’ dapa TT pd: Ex > die Mex > Capd’ dapa Mund) to TRDB. 
(e) Call mp with input (send, ssid, (Ss ‚deer-Cupd> dipa Oupd> P» Opp) in the 
name of P for the 2"* message from P to U. 


(9) Upon receiving output (closed, ssid) from mE for P, do nothing. 


Figure 8.11: The Simulator for Operator Security (cont. from Fig. 8.2) 


sanity check fails, the adversary has caused the transaction graphs to fall apart and the simulator 
immediately gives up the simulation. Each sanity check is related to the security of one of 
the building blocks or cryptographic assumptions. Together, these checks collectively assert 
that the alternative graph structure of the Simulated Transaction Graph coincides with the 
Ideal Transaction Graph and thus no efficient adversary can deviate from the Ideal Transaction 
Graph. 

We proceed by giving concrete (incremental) definitions of all hybrids H? 2 


Hybrid Hy P^5** (The real experiment) The hybrid Hess is defined as 
pp = EXEC ,op-see gop-see Zopsec(1") (8.6) 


with SUE := D being identical to the dummy adversary and m PrSee ,— psc. Hence, HF ae 


denotes the real experiment. 


Hybrid Hj P^** (Fake setup) In hybrid H? P** we modify are such that crs,,,, is gener- 
ated by SetupExt, and crs 2), as well as erst are generated by SetupSim. BIET initializes 
the simulated transaction graph TRDB and Juss and fon as “empty” maps. Additionally, SP 


invokes an internal instance of 208 instead of the external instance 75, and reroutes all 
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8 Security Theorem and Proof 


op-sec 


msc (cont.) 


Simulator S 


Disburse (for honest operator and honest user): (1) Upon reveiving leakage 
(disbursing, pid, ,, Qt) from Fipo E 


(a) Set (pk, sky) = heys(Pidqp)- 

(b) Pick u, È Z}. 

(c) Check if 3 wh = (p”,t”,uz) € Ay s.t. 04, #1 and uz + uz hold.’ 
(d) If yes, t := t" + skqy(uz — uz). 

(e) Provide 7 := sk, to Fape- 


2) Upon receiving leakage (disbursing, s, 9) from %,,. and being asked to 
P 8 8 9 ape 8 
provide (cq, rc), ... 


(a) Set (pkg, 1,1) = fie y (pido) and parse pkg“"* from pk. 
(b) If (t, uz) is not yet defined, pick (t, uz) 2 Zi 

(c) Set wg, := (9. t, uz). 

(d) Set Yc to an arbitrary value from the correct space.‘ 

(e) Set o, = ENC2.Enc(pko sc). 

(f) Provide (cx, @rc) to Fape- 


N.b.: This assignment exists. An honest user must have called RegisterUser previously, otherwise %, would 
already have aborted. 

N.b., even if the user commits double-spending no “useful”, previous double-spending tag may exist in Yo 
if the user only did so at corrupted PoSes that undermine double-spending detection. 

N.b.: This assignment exists. The operator must have called RegisterOp previously, otherwise %, would 
already have aborted. 

Step 1d is only executed, if the user commits double-spending. 

The hidden recalculation tag is of the form ya. = (5,9, p, Pkips Ore) € Gy x Gy x Zp x (G? x G2) x (G2 x Gy), e.g. 
Wee = (1, 1,0, 1, 1, 1, 1, 1, 1, 1, 1) would be a good choice. 
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Figure 8.12: The Simulator for Operator Security (cont. from Fig. 8.2) 


8.3 Proof of Operator Security 


Simulator .S2P *** 


a (cont.) 


Disburse (for honest operator and corrupted user): (1) Upon receiving output 
(establishing-session, ssid, pidqp disburse) from a for O with pido, - 
(a) Set (pkg, sko, certo) = hreys(Pidg) and (pkq,,-) = Feeys(Pidqp; if these 
do not exist, let 7555 abort. 
(b) Parse and pko from pko. 
(c) Call 7552 with input (accept, ssid) in the name of O with pido. 
(2) Upon being requested by Z?P5** to provide the 1* message from O to U ... 
(a) Pick u, = Zp- 
(b) Call > with input (send, ssid, uz) in the name of O for the 1* message 
from O to U. 
(3) Upon receiving output (sent, ssid, (zr, o, bP", t)) from EE for © ... 


cert 


fi rev 
(a) stmnt = (pk, pko pko ,Q, a ,t, ug). 
(b) If P3.Vfy(crspoks stmnt, 7) = 0, let fpc abort. 


(c) Extract Wit = (X, A, Pkap Uy, sPTEV, gPTeV. X, A, Uj, dipa Tie pk e E 
prev  cert,prev prev 
Cfix Opd Op > Ofix» AU: Ip 
(d) Assert that (stmnt, Wit) fullfills the projected equations from i else 
give up simulation (event E1) 
——* 
(e) Lookup trdb. :— (sP'***, s*, 9*, x*, A", pido, pido, p^, b*, UL ah, 
prev,» , prev,* in” jin* in” „in * gin * „in * „out* zout* ,,out* 
Ore "Opp "Chix > dfx Mix > upd da Mand > fix dix ME 
) with s* = sP"®V being used as key; if no unique entry 


ye P3.Extract(Crs poko tdepoks stmnt, 7). 


out* gout* „out * 
Cupd ‚dund t Mind 
exists, give up simulation (event E2). 


(f) Give up simulation if any of these conditions meet: qu + e = (event 


E3), A+ gË (event E4), que * Cg (event E5), pk,, + pku with 
(A*, pk; ) = mout” (event E6 , BPI*V + gb” (event E7), X + g +1 (event 
Psy fix 8i 8i 
E8), or U] + Ur (event E9). 
Call Ene with input (disburse, sP"*V) in the name of U with pid, ,. 
8 apc P piaqı 


Figure 8.13: The Simulator for Operator Security (cont. from Fig. 8.2) 
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op-sec 


asc (cont.) 


Simulator S 


Disburse (for honest operator and corrupted user, continued): (4) Upon reveiving 
leakage (disbursing, pid,,, Qu) from Fape ... 


(a) Check if 3 OA. = (p”,t”,uz) € o s.t. uz + uz and pkey = giku for 
ska = (t — t): (uz - ur mod p holds.’ 
(b) If yes, re-define fieys(pidy,) = (pkqy Sku). 
(c) Provide x = skq to fapc- 
(5) Upon receiving leakage (disbursing) from fpc and being asked to provide ¢, 
return p := PRF(A*, x) with x = x* + 1 to Faye.” 
(6) Upon receiving leakage (disbursing, s, 9) from 7). and being asked to 
provide (c, Wrc), ... 
(a) Set wgs ‘= (@, t, uz). 
(b) Set Y, to an arbitrary value from the correct space. 
(c) Set aye — ENC2.Enc(pk5 ^, Yro). 
(d) Provide (4g, exc) to Fape- 


c 


(7) Upon receiving output (disbursed, bb!!!) from Fape for U ... 


in .— in .— in .— in .— ¿Prev gin . Prev 
(a) Set Chix = Cfixs d; := day mg. :— (A, pk, j), Capd `T Capd ° dnd = dupd 7 


nom prev out .— out .— out .— out .— 
mpd (A, BP U,, X), cee L, der L, mee L, Capd ; 
dout = L, and mont = 

up t 


up 
re ; ; t i i i 
(b) Append (sP!*", s, p, x, A, pid, Pido, p, b, UPS", gg: Ores Opp: Cg din. me, 


in in in out Jout ,,0ut „out ,out ,,out 
Capd Capa: upd’ Sfx > Afix > Méx Capd fapa’ upa) to TRDB. 


(c) Call cr with input (send, ssid, OK) in the name of O for the 2" message 
from O to U. 
sim 


(8) Upon receiving output (closed, ssid) from 71555 for O, do nothing. 


a 


N.b., even if the user commits double-spending no “useful”, previous double-spending tag may exist in [o 
ifthe user only did so at corrupted PoSes that undermine double-spending detection. 

N.b.: Fipe does not always ask for the next serial number. If the corrupted user re-uses an old token, then 
Fapc internally picks the next serial number which has already been determined in some earlier interaction. 
Hence, the Sue only needs to provide the next serial number, if the chain of transactions is extended. 

° The hidden recalculation tag is of the form y, = (8,9, p, pkp» Orc) € Gy X Gy x Z x (G? x G2) x (G2 x Gy), e.g., 
Ye = (1, 1,0, 1, 1, 1, 1, 1, 1, 1, 1) would be a good choice. 


Figure 8.14: The Simulator for Operator Security (cont. from Fig. 8.2) 
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8.3 Proof of Operator Security 


op-sec 


msc (cont.) 


Simulator S 
DetectDS (for honest operator) (1) Upon receiving leakage (detecting ds,c,, 004.) 
from Tape and being asked to provide (pid, y, z, result), ... 
(a) Parse (¢,t, ug) := wg, and (9’,t’, uj) := QA. 
(b) If = o' and uz + uj: 
(i) Set ska, :— (t — t^)/(u5 — u5) mod p. 
(ii) Set pk, :— gh. 
Else, set (pkar sk) = CL, L). 
(c) Set pid,, = freys Pkt -); if pe is not defined for pk, , set pid, = L. 
(d) If pid4, + L, then set (7, result) := (skqy, OK), else set 
Cr, result) := (L, NOK). 
(e) Provide (pid, ,, 7, result) to Fapc- 
(2) Upon receiving leakage (detecting ds, pid,,) from fpc and being asked to 
provide z, ... 
(a) Set (pk,,, sku) = Áieys (pide). 
(b) Provide x = sky to Fape- 
Verify Guilt (for honest party): Upon receiving leakage (verifying guilt, pid, , 2) from 
fpc and being asked to provide result ... 


(1) Set (pk, uem freys(Pidg,)- 
(2) If gf = pk, then provide result := OK, else result := NOK to Fape- 


^ This assignment exist. (detecting ds, pid,,) is only leaked, if the user truly committed double-spending. In 
this case Step 5 in Fig. 8.9 and Step 4 in Fig. 8.13 have been called previously. In all other cases the honest 


user and therefore SP. knows sky, anyway. 


Figure 8.15: The Simulator for Operator Security (cont. from Fig. 8.2) 
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op-sec 
TIP5C 


Simulator S (cont.) 


BlacklistWallet (for honest operator): Upon receiving leakage (blacklisting_wallet, A, 
x) from %p. and being asked to provide y, provide ø := PRF(A, x) to Fapc- 


RecalculateBalance (for honest operator) Upon receiving leakage 
(recalculating balance, blg, Qf*°) from Tape and being asked to provide gpeviate — 
(1) hake = (ys, E ENC2.Dec(sk5 ^5, ye) | Wye € Qgke) 
(2) wpakevalid = ((s p, p, pkp, Orc) € Yre | SIG. Vfy(pkg. arc (s. 9. gf) = 1] 
(3) E= (p) | Bc = (S9 p.) € VEI y € bla} 
(4) Provide poe = 2i pez? to Fape- 


Figure 8.16: The Simulator for Operator Security (cont. from Fig. 8.2) 


op-sec 


input/output accordingly. All calls to the bulletin-board Fpp are handled internally by S} 
using the map hes 


Hybrid Hr (Simulate honest keys) Hybrid HF “Sec replaces the code in the tasks 
;P-*** such that the 
simulator S, 2P-** is asked for the keys instead. Also, if corrupted PoSes or users try to register a 
?P *** calls RegisterPOS or 


RegisterUser, resp., in order to simultaneously register the parties for Zaye. SETS defines Ties 


RegisterDR, RegisterOp, RegisterPOS and RegisterUser of the protocol 7, 
(maliciously) generated public key at the bulletin-board Fpp, then S, 


appropriately. This equals the method in which the keys are generated in the ideal experiment. 


Hybrid H5" *** (Simulate PoS’ certificate) In hybrid H;P ^^ the task CertifyPOS is mod- 
ified. The protocol niv is modified such that the simulator sr receives the mes- 


sage (certifying_pos, pidp, ap), creates the certificate certp including the signature of" and 


op-sec 


records it. Whenever the honest operator or honest PoSes running 77 would send cert (or 


og") as part of their messages in the scope of IssueWallet or Deposit, they omit certp. Instead, 


op-sec 


the simulator S, injects certp into the messages. 


Hybrid nee (Simulate wallet signatures and wallet update information) Hy- 
brid HE se replaces the code in the tasks IssueWallet and Deposit of the protocol i = 
such that the operator/PoS do not create signatures, but the simulator Erd *** creates the 
signatures Ofix» Oupd and oy, resp. and injects them into the messages a 

Moreover, in Deposit in case of a corrupted user the PoS running m ** does not send Cupd 
and dupd i in its final message, but outputs the price p to simulator B sec as Tape Would do. 


Simulator see creates Cypg and dip q honestly and injects them into the message. 
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op-sec 


Simulator 5;,.. 


(cont.) 


ProveParticipation (for honest user and honest violation enforcer): (nothing to do, note 
that Zap. only leaks, if user or violation enforcer is corrupted) 


ProveParticipation (for corrupted user and honest violation enforcer): (1) Upon 
receiving output (proving participation, pid, Qpp) from fpc for U with 
pid, call =: with input (establish-session, ident, pid, , 
prove participation) in the name of VE. 

(2) Upon receiving output (accepted, ssid) from Fane for VE, call Fane with input 
(send, ssid, (pid,, Qpp)) in the name of VE. 
(3) Upon receiving output (sent, ssid, (pp. VppJ) from Fane for VE, ... 
(a) Set (pk,,, ) = Fkeys(Pidap and (pkg, -,-) = keys pid p)" 
(b) Parse pk from pkp. 
(c) Set (Ji, pz) = foy app). 
(d) Set Cpk,,, = Opp: 
(e) Parse (-, Opp; dok) := Yop and (Sepp. dry, ) = Vip” 


(f) If Yop =lor SIG. Vfy(pk? Op» pk) =0or C2.Open(ers m pkap Coke 
doky) = 0, call 74, with input (proving participation, L) in the name of 
U. 
(g) If Yop = L, i.e., @pp has not legitimately issued, and pid, € PLD opr, give 
up simulation with event E10. 
(h) If C2.Open(ers An, pk, Cpk, > Ip) = 1 and pk,, + pk;, + L, give up 
simulation with event E11. 
(i) Call Fape with input (proving_participation, Opp) in the name of U.‘ 
(4) Upon receiving leakage (proving participation)from iy. and being asked 
to provide result," provide result = OK to Fane. 


(5) Upon receiving output (proved participation) from Apc for U, call nd 
with input (close, ssid) in the name of VE. 


These assignment exists, otherwise Fip: would already have aborted previously. 

If fpp(@pp) is undefined, we stipulate Jp, = 1 and set oj, = dy. - 

Ypp = L holds, if and only if jj, is made up by the environment. In this case and if the PoS is corrupted, too, 
Step 4 will be executed. 


N.b., fpc only leaks this, if wp has not legitimately been issued and the PoS with pid, is corrupted, too. 


Figure 8.17: The Simulator for Operator Security (cont. from Fig. 8.2) 
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op-sec 


asc cont.) 


Simulator S 


ProveParticipation (for honest user and corrupted violation enforcer): (1) Upon 


receiving output (establishing-session, ssid, pid yp, prove_participation) 
from fus for U with pid, ,, call Ais; with input (accept, ssid) in the name of 
U. 

(2) Upon receiving output (sent, ssid, pidp, App) from Tae for U, call Tape with 
input (prove participation, pid, ,, pid, App) in the name of VE. 

(3) Upon receiving leakage (proving participation, (pp) from Fape, let Fane 
continue. 

(4) Upon receiving output (proved participation, result) from Tape for VE, ... 


(a) If result = NOK, set Vpop := 1, else 
(i) Set (pk,,, -) = Jieys pid.) 
(ii) Set (pp: E Fpp(@pp)-“ i 
(iii) Set Cok, = Opp and parse (KT, Opp: doky) = pp. 
(iv) doky “e C2.Equivoke(crsQ),, pk. y Cpk, dy. )- 
(v) Redefine y, := (KE? Opp» doky) and fop(@pp) = (pp. pk. 
(b) Call er with input (send, ssid, (pp, Ypp)) in the name of U. 
(5) Upon receiving output (closed, ssid) from a for U, let fpc delivers its 
output to U. 


^ This exists as otherwise fip: would have returned result = NOK. 
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Figure 8.18: The Simulator for Operator Security (cont. from Fig. 8.2) 


8.3 Proof of Operator Security 


Hybrid HP e (Simulate serial number) gp modifies the tasks of IssueWallet and 
Deposit in case of a corrupted user. The code of mt see for the operator/PoS is modified 
such that it does not send cz, in the scope of IssueWallet or Deposit. Instead di see runs 
(chars dg) — C4.CommitSim(crs\),,) and injects c{,, into the message. Moreover, m for 
the operator/PoS is modified such that it uniformly and independently picks s = Z, and 


passes s to S; PS as part of the final message. SIE *** calculates s” := s- (s/)-!, executes 
di. = C4.Equivoke(ers 2, tdeqcom: S”, Cser» dzer) and injects s” together with d/^, into the 


messages from operator/PoS to the user. 


Hybrid He Psee (Recover wallet ID and scrutinize equations) When so. receives a 
NIZK proof 7 in the scope of IssueWallet, Deposit and Disburse, it extracts the witness and 
recovers A := À” + Sa DLOG(A/)- Bi. 


Moreover, the verification of the proof is moved from Me P"S for the honest operator/PoS 


op-sec 


to the simulator. If the verification fails, S¿ aborts as the operator/PoS running the real 


protocol would do. 


Additionally, SE sec checks if the pair of the statement and the extracted witness fulfills the 


(1) 12) and i5 Op-sec 


languages L5, Lys, resp. If not, S¿ 


give up the simulation with failure event (E1). 


Hybrid HP see (Record Tags) He sec replaces the code protocol i *** of the tasks 


IssueWallet, Deposit and Disburse such that the various tags are not exclusively created by 


the parties’ code but with support from a and then recorded by SP sec. More precisely, 
these are 

cy = (A”, Jj) wgs = (9, t, uz) (8.7) 

c €- ENC2.Enc(p ko nk) Opp `= Cpk,, (8.8) 


To this end, a P°see and SIC are changed in detail as follows. 


For the blacklisting tag œ: In the scope of IssueWallet the honest operator does not pick the 
share A" of the wallet ID and sends it, but lets ST = 


message. When the honest or corrupted user sends? yj, se removes it from the 


pick A” and inject it into the 


message and the code of operator is modified such that operator does not expect to 


receive jjj. Instead, the operator asks S ns 


op-sec 


to provide the final «yj; which is then 


output by operator. Also, S, records fo (A) = «yj as fac would do‘ 


3 mere sec 


N.b.: S77 7** controls $33? and therefore also sees the message of an honest user that runs 7. 
* sees kiigws A due to hybrid He? °° 
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For the double-spending tag wgs: In the scope of Deposit/Disburse the honest PoS/operator 
does not pick the DS challenge u, and sends it, but lets E pick u, and inject it into the 
message. When the honest or corrupted user sends the DS response t, ap removes it 
from the message and the code of PoS/operator is modified such that they do not expect 
to receive t. Instead, they ask sr to provide the final wgs which is then output by 
operator. Also, the code for honest users is modified such that it explicitly leaks s, to 


S This equals the behavior of fpc- 


For the recalculation tag @,.: In the scope of Deposit/Disburse the code gt m of the honest 


PoS/operator is modified such that they ask SP sec for the final c, which is then output 
by PoS/operator. To this end they provisionally leak the honestly created wfe to STE 
which replies with c, := @t.. Also, the honest PoS additionally leaks p in the scope of 


Deposit, if the operator is corrupted? 


For the prove-participation tag (pp: When the honest or corrupted user sends c,z, in the 
u 
scope of Deposit, see removes it from the message and the code of the honest PoS is 
cp. Instead, PoS asks SIPS to provide 
Da, 7 
the final yy which is then output by PoS. Also, the code of PoS is modified such that it 


does send ay, back to user, as it cannot sign cy, anymore. Instead, the m P^*** leaks pid, 


modified such that it does not expect to receive 


to SU which then runs opp — SIG.Sign(sk7?, Cok.) as the PoS would do and injects 


Opp into the response from the PoS to the user. Please note, that Ses knows the secret 


PP 
key skEP as the PoS is honest. Moreover, the code of the honest user is modified such 


that it asks See for the final c, which is then output by user. To this end, the code 


op-sec 
77 


(opp: Vp) to SP“ which replies with Opp ‘= @pp and defines fop (epp? = (Upp pk. 


for honest users is modified such that they provisionally leak the honestly created 


In summary, these modifications leak (s, 9) (for wg.-tags), pid, (for wpp-tags) and—in case of a 


corrupted operator in Deposit—also p (for w,.-tags). This equals the behavior of the final Faye 
op-sec 


(cp. Fig. 4.11, Step 10 and Fig. 4.12, Step 7). On top, 7, provisionally leaks cx, and «y, which 


are still honestly created by m, PS and simply mirrored back by ST AS Wye and (pp, resp. 


This over-leakage is reverted in hybrids He e and i ae 


op-sec 


Hybrid Hs P^** (Create simulated transaction graph and lookup tables) When Sg 
receives a NIZK proof zin the scope of IssueWallet, Deposit and Disburse, it uses the extracted 
witness from hybrid gr to assemble all parts of trdb and appends trdb to TRDB. This also 


> . : Op-sec 
includes wp]; Ods: re and cy created in the hybrid pH 


^. N.b., for operator security the operator is always honest, i.e. the latter case never holds. However, we explicitly 
consider this case here, as this allows us to reuse this hybrid as hybrid H, to prove user security. 
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8.3 Proof of Operator Security 


When a new entry trdb is assembled in the scope of the tasks Deposit or Disburse, S ade 


compiles the set a. = tos. | Gere) € TRDB} as Tape would do. If there exist 
matching double-spending tags was c4. € 2. then set f,(pidq,, 7) := OK with 7 := skqy to 
record this incident of double-spending as s» a would do. If pidq, € PLD corr reconstruct 
"da would do first and redefine espa (pidq,) = (pkq sku) (cp. Step 5 in Fig. 8.9 and 
Step 4 in Fig. 8.13). 


skq as S 


Hybrid Hob see (Check predecessor) In the scope of Deposit or Disburse, the simula- 
tor SU NES 


SE sec gives up the simulation with event E2. 


looks up the predecessor entry with sP'*" being used as the unique key. If this fails, 


Hybrid Hi *** (Check updatable part of wallet) The simulator SQ *** additionally checks 


for Du + we and gives up the simulation with event E3, if the check succeeds. 


Hybrid HT see (Check wallet ID) The simulator Sa *** additionally checks for A + gr 


and gives up the simulation with event E4, if the check succeeds. 


Hybrid HT see (Check fixed part of wallet) The simulator Sie sec additionally checks for 


p # cg, and gives up the simulation with event E5, if the check succeeds. 


Hybrid Hj sec (Check user ID) The simulator SEM parses (A*, pk) = mont” and checks 
for pk, + pk. If the check succeeds, it gives up the simulation with event E6. 


Hybrid Hj? ^^ (Check balance) The simulator S7? ^ additionally checks for BP!*V + gr 


and gives up the simulation with event E7, if the check succeeds. 


Hybrid HP see (Check transaction counter) The simulator SE Mia 


X # gt "+1 and gives up the simulation with event ES, if the check succeeds. 


additionally checks for 


Hybrid HI Sec (Check DS mask) The simulator SE c additionally checks for U; + U* 
y y 1 


and gives up the simulation with event E9, if the check succeeds. 


Hybrid Hy *** (Utilize lookup tables for DetectDS) This hybrid modifies the code mi Mr 
for O in the task DetectDS. In the task DetectDS the honest O becomes a dummy party, too, 
which simply forwards its inputs wg, and w4, The code is moved to the simulator and se = 
uses its “lookup table” TRDB the same way as the Tape and the final simulator SR does. 
More precisely, for legitimately issued, distinct and matching double-spending tags, B = 


looks up (pk, sku) = Áieys pida), returns 7 := skqy and records f; (pid, ,, 7) := OK. 
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Hybrid HP "Sec (Utilize lookup tables for VerifyGuilt) This hybrid modifies the code 


mr “SS for parties in the task VerifyGuilt. The honest party does not locally run the algorithm 
; : - : op-sec 
itself, but simply forwards its input to the simulator (as the dummy party would do) and S;, 
Op-sec 


queries f; (pid, t) as Fip would do or proceeds as Sy... 


defined. 


‚if fr (pid, 7) has not yet been 


Hybrid Hye © (Utilize lookup tables for BlacklistWallet, forego decryption of black- 


listing tags) The dispute resolver DR becomes a dummy party and simply sends it input 


(blacklist wallet, pid, /) to the simulator SEC in order to signal its consent to blacklist the 


op-sec 
9 


user. The simulator S} utilizes the Simulated Transaction Graph TRDB as well as fo, and 


runs the code as the ideal functionality fpc would do eventually. Especially, sy see does not 
decrypt cyj, but uses the recorded foo) from hybrid HP® to determine the original A* 
Hybrid Ha (Utilize lookup tables for RecalculateBalance, forego decryption of 
recalculation tags) This hybrid utilizes TRDB to link legitimately issued recalculation tags 
to their origin. 

When the task RecalculateBalance is invoked, se partitions the set of recalculation tags 
Q,. into two set oo and (fake the same way as Jap. Would do (cp. Figs. 4.16 and 8.16). 
€ pre is queries TRDB to create a set 


Recalculation tags wre are not decrypted, but 3 


Zgenuine ,— {(s, p)}. Recalculation tags wre € Of3ke are still decrypted, their signature is checked 
for validity and Sfke := {(s, p)} is compiled from the decrypted values. Then the balance is 
calculated as pill .— by p)ezgenuine pt Ds peste P. i 

This behavior equals the joint behavior of fpc and the final simulator SHES (cp. Figs. 4.16 


7Ipsc 
and 8.16). 


Hybrid He "Sec (Utilize lookup tables for ProveParticipation, check signature) This 
hybrid utilizes fy, to assert that prove-participation tags are honestly signed. This sanity 
check is a preparatory step for the eventual switch from the real code to the ideal code in 
hybrid H7? “°° by ruling out that a corrupted user forges signatures. 

More precisely the following changes are applied by HE “eS in the scope of ProveParticipation 
for an honest violation enforcer interacting with a corrupted user: 

The party VE becomes a dummy party and simply forwards the input pid,, and set of prove- 
participation tags Qpp to SIC. The simulator interacting with Z°P°S°“ still runs the real code 
(as a real VE would do), but utilizes its map fpp to add the following check. When Z?P'*** 


(playing the corrupted user) sends wpp and pid, is honest, the simulator tries to look up its 


° The operator is honest and the real code would abort for a «yj that has not legitimately been issued. Hence, 
fa, (tj) is always defined. 
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original complement (5. pk) = fop(@pp)- If this does not exist, i.e., if Ypp = L, but ZP Ses 


has provided a valid signature, then the simulator gives up the simulation with event E10. 


Hybrid HP see (Utilize lookup tables for ProveParticipation, check user ID) Similar 
to Ha this hybrid introduces another sanity check in the scope of ProveParticipation in 
case of a corrupted user and an honest violation enforcer: 
If an original complement (Y, pki) = I) for Wpp exists but the environment Z°PS°¢ 
unveils the commitment cy 
u 
simulator gives up with event E11. 


= Wpp toa different Pky than it has originally been issued, the 


Otherwise it still runs the real code for ProveParticipation. 


Hybrid Hoe "eS (Utilize lookup tables for ProveParticipation, forego unveil of prove- 
participation tags) This hybrid utilizes TRDB and Jop to link legitimately issued prove- 
participation tags to their origin. More precisely, the following changes are applied by HE Se 


in the scope of ProveParticipation: 


For a corrupted user and honest violation enforcer: This hybrid completes the changes intro- 
duced by hybrids 2 nin and HEU. When Z?P*** sends oy, Ypp in the name of the 
corrupted user, the simulator first checks if the commitment unveils correctly and if the 
signature is valid. If anything is inconsistent, the simulator runs the code of the ideal 
functionality with input Wpp := 1. Also, if the sanity checks of both previous hybrids 
pass, then the code of the ideal functionality is executed with the provided cy, as its 
input. If the ideal code asks for a result bit (because wp, is unknown and the PoS is 
corrupted), the simulator returns result = OK. This equals the joint behavior of the final 


simulator .S?P-*** (cp. Fig. 8.17) and Faye (cp. Fig. 4.17). 


For an honest user and corrupted violation enforcer: The code of the honest users is modified 
such that they do not send (pp, Yop) but only Opp- Also, the users do not internally test, 
if pp is one of their own prove-participation tags, but simply forward them as a dummy 
party would do. SEU uses TRDB to link (pp to its original transaction and thereby 
determines the result. If the result is positive, A ade looks up the corresponding Ypp 
in fpp and simulates the message (pp, Ypp). Note, Ypp are not yet equivocated (as the 
final simulator would do), but se sends the original y, that have been recorded in 


hybrid HP T 


Hybrid Hey see (Fake blacklisting tags for honest users) The code ni "Sec for honest 
users in the scope of IssueWallet is modified such that they do not send a). Instead, SE US 
returns wp) := (A", Ypi) with Jg; = ENC1.Enc(pk pp» (1,...,1)), when O asks for a «yj (cp. hy- 
brid HP S: 
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Hybrid Hee see (Fake double-spending tags for honest users) The code A sec for hon- 
est users in the scope of Deposit and Disburse is modified such that they do not send a real DS 


op-sec 


response t. When the operator asks for double-spending tag (cp. hybrid H} ), the simula- 


tor SET * proceeds as follows. SIE ses compiles the set an = {of A (0, .. noi ^.) € TRDB}. 


(N.b., this already happens for corrupted users in hybrid n "m to recover their secret key). 


op- sec 


R ; 
picks t — Z, randomly. Otherwise 
op-sec 
"ipsc 


If no (p,1’,u3) € o. has been recorded previously, S, 
SE Sec sets t := t" + skqy(uz — uj). This equals the behavior of the final simulator S 


Hybrid HE (Fake recalculation tags for honest users) The code mr sec for honest 


operator/PoS in the scope of Deposit and Disburse abandons the over-leakage of w;, that has 


Op-sec 


provisionally been introduced by hybrid H; . When they ask for c, the simulator does 
not simply reflect c :— cf, but instead creates w,. on its own. The simulator does so in two 
different ways, depending on the corruption status of the operator. 

If the operator is corrupted, the simulator creates Ype := (s,Q, p, pkp» Orc) with 07. € 
SIG.Sign(skp, (s, p, g?)) faithfully and provides a true encryption wre + ENC2. Enc(pko’ e dich 
We stress that SE *** knows all relevant information s, q, pid, and p due to the leakage intro- 
duced by hybrid He FUE 

If the operator is honest, SES * provides an encryption c,  ENC2. Enc(pky' RE Were) for 


an arbitrary Y, from the correct space. 


Hybrid Hy "Sec (Fake prove-participation tags for honest users) The hybrid HE sec nod- 
ifies Deposit and ProveParticipation. 
In Deposit the honest users do not leak (pp, Ypp) anymore. This leakage has provisionally 


been introduced by hybrid Br *** Instead, S, “a *** simulates the commitment as (c, d g, ) + 
DKap PR 
C2.CommitSim(crs2,) and runs op, — SIG. Sign(skIP, c Cp. ). S Sec Sets Opp = Cpky and 


pp = (KP, Opp» dor)» returns (pp and defines Sop pp) = (Jpp. 81). 
Moreover, the code for ProveParticipation in case of an honest user and a corrupted viola- 


tion enforcer is adapted (cp. hybrid HF sec), After S$ *** has looked up the corresponding 


op- sec 


Vpp: a) = = am but before sending V; to Z^? *** playing the corrupted VE, S, parses 


(pri? , Opp» d pk, = = Ypp), equivocates the decommitment d pku © C2. Equivoke( crs, pk, 
Cp, pk)» redefines Ypp = = (pkyP > Opp» doky) and then sends Jop: 


op-sec 


Again, this equals the behavior of the final simulator S77 


For the proof of Theorem 8.2 we show the indistinguishability of subsequent hybrids by a 


series of hybrids. The hybrids HE Ps to A, p and Rp are rather trivial and thus 


Lemma 8.5 handles various hybrids at once. 


7. N.b., for operator security the operator is always honest, i.e. this case never holds. However, we explicitly consider 
this case here, as this allows us to reuse this hybrid as hybrid H,, to prove user security. 
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Lemma 8.4 (Indistinguishability between Hy PES and H? P^*7) Under the assumptions 
of Theorem 8.2, Hoe £ Heo holds. 


Pnoor This hop solely changes how the crs is created during the setup phase. This is indis- 
tinguishable for crs,og, and crs), (see the extractability property of Definition 6.9 and the 
equivocality property of Definition 6.11, resp., condition (a) each). " 
Lemma 8.5 (Indistinguishability between their respective predecessors and Hy inr 
m. i S, MN. nee, resp.) Under the assumptions of Theorem 8.2, HT = 
jppes £ a £ Pec nud Horses £ HoP-sec £ A hold 


Pnoor The hops are all indistinguishable as they do not change anything in the view of 
ZP’seC, Please note, that Z?P 5** only sees the in-/output of honest parties and these hops 
only syntactically change what parts of the code are executed by the parties or by the simulator. 
With each hop the parties degrade more to a dummy party while at the same time more 


functionality is put into the simulator. " 


Lemma 8.6 (Indistinguishability between Cc and He P***) Under the assumptions 
of Theorem 8.2, He £ pu holds. 


Pnoor This hop is indistinguishable as the equivocated decommitment information is perfectly 
indistinguishable from a decommitment that has originally been created with the correct 


message (cp. Definition 6.11, Item (3)). " 


So far, none of hops between two consecutive hybrids changes anything from the envi- 
ronment's perspective: either the hops are only syntactical or the modification is perfectly 
indistinguishable. Hence, no reduction argument is required. In the contrary, each of the 
upcoming security proofs roughly follows the same lines of argument. If the environment 
ZP" can efficiently distinguish between two consecutive hybrids, then we can construct 
an efficient adversary 8 against one of the underlying cryptographic building blocks. To 
this end, 8 plays the adversary against a particular security property in the outer game and 
internally executes the UC-experiment in its head while mimicking the role of the simulator. It 
is important to note that although 8 emulates the environment internally, it only has black-box 
access to it. In other words, although everything happens inside “the head of 8” it cannot 


somehow magically extract Z/?P 5€*'s attack strategy. 


Lemma 8.7 (Indistinguishability between He PS and Hg P**5) Under the assumptions of 
Theorem 8.2, He £ nre holds. 
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Pnoor First note that the only effective change between He Prsee and He P"SEC are the additional 
checks that abort the simulation with event El, if the extracted witnesses are invalid. Again, the 


other modifications are purely syntactical. To proof indistinguishability between He Prsee and 


Hg P-sec we split this hop into three sub-hybrids. Each sub-hybrid introduces the check for one 


of the languages Ly In and 1O, 


Ly is considered, the indistinguishability of the remaining two is proved analogously. Further 


resp. In the following only the sub-hybrid for the language 


note, that the view of Z*P"" is perfectly indistinguishable, if the simulation does not abort. 
Assume there is an environment ZP" that trigger the event El in the first sub-hybrid 
with non-negligible advantage. This immediately yields an efficient adversary 8 against the 
extraction property of the NIZK scheme. Internally, B runs Z?P*** in its head plays the role 
of the simulator and all honest parties. Externally, 8 plays the adversary in Definition 6.9, 
Item (3b). If the event E1 occurs internally, 8 outputs the corresponding pair (stmnt, x). In 
the second and third sub-hybrid 8 internally extracts the witness for the previous sub-hybrid 


using the extraction trapdoor tdepok which 8 obtains as part of its input. = 


epo 


Remark 8.8 We observe that Lemma 8.7 implies that the equations 


C1.Open(ers(),,, m, Cex» dg,) = 1 with m= (A, pk, (8.9) 
Ci.Open(crs m, c upd: dupa) =1 with m= (A, 1,0 £1) (8.10) 
C1. Open(crs()) ‚m, Capa? dpd) = =1 with m = (A, BP’ Uj, X) (8.11) 
C1.Open(crs\),,, m, , Capd? dipa) = =1 with m = (A, Bue X) (8.12) 
C3.Open(crsQ),, A’, c? ig Aia) =1 (8.13) 
C2.Open(ers am pk, Cok? pk) =1 (8.14) 
and 
SIC. Vfy(pkD", os... m)-1 with m= (cg, au) (8.15) 
SIG. Vfy(pkzP Prev. ong sm) = 1 with = (eg, Pre) (8.16) 
SIG.Vfy(pk5", gu P, m)-1 with m= (pk, ue (8.17) 
(8.18) 


resp., hold and that all variables can efficiently be extracted. Remember, that F, acts as the 


identity function on group elements. Likewise, the equation 


T- pki -U with T= g (8.19) 
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holds. Note, that the Zy-elements t and uz cannot be extracted, but are known and part of the 
statement. Moreover, given the extracted chunks of the wallet ID Ac, ..., A; , the unique wallet ID 
A can be reconstructed. The projection F,, becomes injective if the pre-image is restricted to Zy 


and the inverse, i.e. DLOG, can be efficiently computed as A;,..., Ag_, are sufficiently “small”. 


Up to this point, we already know that Ho pon Hg P’se¢ holds. Except for two small changes 
(from ae to Hee and from nee to ine) all hops are only syntactical. 

The remaining subsequent hybrids can roughly be divided into two groups. The hybrids 
from gp to HT see cover modifications that affect corrupted users while HS edo Hy TRES 
cover modifications that affect honest users. 

The hybrids we deal with first, i.e., hybrids Hj rig Ha 2 3, only add more sanity checks but 
do not change any messages. However, only TRDB and these sanity checks enable a reduction 
to cryptographic assumptions and thus are vital to prove operator security. Intuitively, these 
sanity checks assert that a malicious user cannot make the simulated transaction database and 
the ideal transaction database fell apart without immediately being noticed or the malicious 
user has successfully broken a cryptographic assumption. To this end, two additional lemmas 
about the structure of TRDB are necessary. These lemmas are in the same spirit as Lemmas 5.2 


and 5.3. Intuitively, the commitments Cf, c,,,4 induce a graph structure onto TRDB comparable 


Cup 
to the wallet ID A and serial number s. 


Lemma 8.9 (Forest Structure of the Simulated Transaction Graph) 
(1) Every trdb = (sP'*V, s,...) € TRDB is uniquely identified by s with overwhelming probability. 


2) The Simulated Transaction Graph TRDB is a forest with edges defined by (sP**Y, s). 
(2) p g y 


Proor (1) A new entry is only inserted in the scope of IssueWallet, Deposit or Disburse. 
Proof by Induction: The statement is correct for the empty TRDB. For each insertion, the 
simulator a (and every following simulator) draws s uniformly and independently. 


The chance to pick a serial number that has already been used is negligible. 


(2) As the serial number s of the new node is randomly chosen, no existing node can point 
to the new node as its predecessor and thus no cycle is closed with overwhelming 


probability. " 


Lemma 8.10 (Indistinguishability between Hz P5** and He P^5**) Under the assumptions 
of Theorem 8.2, Ha £ He holds. 


Pnoor Assume there is an environment ZP“ that trigger the event E2 with non-negligible 


advantage. This immediately yields an efficient adversary 8 against the EUF-CMA security of 
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SIG. We only need to deal with the case that s* does not exist. If it exists, Lemma 8.9, Item (1) 


implies its uniqueness. We need to distinguish two cases. On an abstract level these cases 


correspond to the following scenarios: Either the previous PoS exists. Then the signature Ord 


prev 


on (cind und ‚sP'eV) is a forgery. Or alternatively, the allegedly previous PoS does not exits but has 


prev sPrev) may have an honest, valid signature (because the 


been imagined by the user. Then (Copa 
user feigned the PoS), but the edicts certh SY for the fake PoS constitutes a forgery. Please 
note, that the simulator always records an entry trdb when it legitimately issues a signature 


upd and vice versa. 


(1) A record pide” > e (pk, s kb") has been recorded: In other words, (Cf sP!eV) has 
never been legitimately issued by the allegedly previous PoS.* We comia an efficient 
adversary 8 against the EUF-CMA security of SIG. Internally, 8 runs Z?P 5€ in its 


head and plays the role of the simulator and all honest parties. Externally, B plays the 


SIG 
O pro prev skype prev* 


EUF-CMA security experiment with a challenger C and a signing oracle 
B needs to guess for which pido the event (E2) eventually occurs. When tlie PoS 
with pid registers itself, and B playing B needs to internally provide pk” = 
( pkypaprey pkp” rev) it embeds the external challenge public key as mal Whenever 


Op-sec 


B playing the role of S, 


its external EUF-CMA oracle one prev spipdpre When the event (E2) occurs, 8 extracts 


(pa sP'*V) and oP pd V from the Brot and outputs the forgery. N.b., (ea SP) has 


needs to issue a signature with respect to pkg ‘prev it uses 


upd,prev 


never been signed with respect to pkg by assumption. 


(2) A record pid” > (pk, Shes certp) has not been recorded: We construct an effi- 
cient adversary 8 against the EUF-CMA security of SIG along the same lines as above. 
Internally, 8 runs Z?P5** in its head and plays the role of the simulator and all hon- 
est parties. Externally, 8 plays the EUF-CMA security experiment with a challenger 


C and a signing oracle or When the adversary 8 has to internally provide 


ice cert* 
pko .sko 


pko = (pk p ko d pk a’, pko sig, pko enc) playing the role of Sr sec in the scope of 


RegisterOp, 8 ae the external dolis public key as pko”. 


Whenever 8 playing 
the role of a *** in the scope of CertifyPOS Certification needs to issue signatures 


with respect to pk5™, it uses its external EUF-CMA oracle One "m When the event 


(E2) occurs, B extracts certo" = (pkp. ap, 05°‘) from the prooi and outputs (pkp, ap) 
together with 05°"! as the D N.b.: (pkg, ap) has never been signed by the operator 


8 


N.b.: PoS may also denote the operator, if the transaction at hand happens to be the first after a IssueWallet and 
thus s* has been signed by the operator playing the role an PoS. For brevity, we only consider PoSes here. 
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with respect to pko" as otherwise a mapping pid > (pk, 85 certo) would 


have been recorded. 


The forgeries are indeed valid due to Remark 8.8. " 


Remark8.11 Without Lemma 8.10 it is unclear in Lemma 8.9, Item (2) ifthe denoted predecessor 
of edge (sP'**, s) actually exists. The simulator extracts the serial number sP!*Y of the predecessor 
from the proof and puts this serial number into the newly added trdb. With this in mind Lemma 8.9, 
Item (2) would have to be interpreted such that an edge (sP'*", s) is ignored, if the predecessor did 
not exist. Nonetheless, TRDB is still a forest and Lemma 8.9, Item (2) remains correct. Anyway, 


this oddity is ruled out by Lemma 8.10. 


Lemma 8.12 (Indistinguishability between Hy 


op-sec C ,,op-sec 
of Theorem 8.2, Ho = Hg holds. 


P7** and HI? ^^^) Under the assumptions 


Proor Assume there is an environment Z?P** that trigger the event E3 with non-negligible 
advantage. This immediately yields an efficient adversary 8 against the EUF-CMA security of 
SIG by the same argument as in the proof of Lemma 8.10 as (Copa 
the same signature oy)4. " 


, sPI*Y) are jointly signed by 


Lemma 8.13 (Indistinguishability between HE see and HP ES) Under the assumptions 
of Theorem 8.2, HI £ o holds. 


Proof Assume there is an environment ZP" that trigger the event E4 with non-negligible 
advantage. We construct an efficient adversary B against the binding property of C1. Internally, 
B runs Z°P°° in its head and plays the role of the simulator and all honest parties. Externally, 
8 plays the role of the adversary as defined by Definition 6.11, Item (2). When the event (E3) 
occurs, £ sets 


md := (A, BPeY U}, X) (8.20) 


from the extracted witness and obtains 


mout” = ABU (8.21) 


from TRDB. 8 outputs Cu m’ pa dr mou, dou) to the external game. By assumption 


A + A” holds and Remark 8.8 asserts that both openings are valid. " 


Lemma 8.14 (Tree-wise Uniqueness of the Wallet Identifier) The wallet ID À maps one- 


to-one and onto a connected component (i.e., tree) of the Simulated Transaction Graph. 
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Proor Same argument as in the proof of Lemma 5.3. " 


Lemma 8.15 (Indistinguishability between H7 ^^^ and Hj? ^^) Under the assumptions 
of Theorem 8.2, HE a D sec holds. 


Proor We introduce a sub-hybrid that splits between two cases why event E5 is triggered: 
y P y 88 
(1) or + Cf, and cg, is not recorded in any trdb € TRDB. (2) or # cg, and cg, is recorded 


in some record mi € TRDB. An environment Z?P-5*€ that can differentiate between d = 


and the sub-hybrid yields an efficient adversary 8 against the EUF-CMA security of SIG. 
An environment ZP" that can differentiate between the sub-hybrid and H7 ^^^ yields an 


efficient adversary 8 against the binding property of C1. 


(1) We construct an efficient adversary B against the EUF-CMA security of SIG. Internally, 8 
runs Z?P 5€ in its head, and plays the role of the simulator and all honest parties. Exter- 
nally, 8 plays the EUF-CMA security experiment with a challenger C and a signing oracle 
O5IG a When 8 must internally provide pkg = (PKS, p ke a p, i pko ™) 

pk skr 
playing the role of S, 


= sec in the scope of RegisterOp, 8 embeds the external challenge 


op- sec 


public key as pko: ` Whenever 8 playing the role of S; needs to issue signatures 


with respect to pk ex , it uses its external EUF-CMA fens OF ie " When the event 
PRo »SKo 
(E5) occurs, B extracts cg, and og, from the proof and outputs the forgery. 

(2) We construct an efficient adversary 8 against the binding property of C1. Internally, 
B runs Z?P **€ in its head and plays the role of the simulator and all honest parties. 
Externally, 8 plays the role of the adversary as defined by Definition 6.11, Item (2). As 
(E5) has not been raised earlier, c gut) _ cout* # cg, holds for all cout in the same 


Cx 


out i 


tree. Consequently, db with cg. = cg, is part of a different tree in TRDB and thus 


A* # A* = A follows by Lemma 8.14. 8 sets 

Ig = (A, pk) (8.22) 
from the extracted witness and obtains 

mps = (A5 pk) (823) 


from TRDB. 8 outputs (cg, Mg» dfx» mout®, dou) to the external game. 


Remark 8.8 asserts that the forgery in (1) and both openings in (2) are indeed valid. " 


Lemma 8.16 (Indistinguishability between Hj) °°, Hi? °°, Hj] HP" and Ho) 


op- sec € Eo: sec € jjop-sec C ,jop-sec C  ,op-sec 
Under the assumptions of Theorem 8.2, H, 3 =H  =HE 16 holds. 
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Proor If an environment Z?P'**€ can distinguish between any of the hops from Hj? ^. to 


iT 7 this yields an efficient adversary against the binding property of C1. As usual, 8 
runs Z?P **€ jn its head and internally plays the role of the simulator and all honest parties. 
Externally, $ plays the role of the adversary as defined by Definition 6.11, Item (2). If event 
(E7) or (E8) occurs, 8 sets 


mb = (A BP U, gX) (8.24) 


from the extracted witness and obtains 


mod = (A*, B*, UŽ, X*) (8.25) 


TRNR prev ‚prev , out* yout* 
from TRDB. 8 outputs (Capa; apa Gnd , Mapd did ) to the external game. If the event (E6) 


is triggered, 8 proceeds analogous but for the fixed part of wallet cz, " 


Again, we interrupt the line of argument to summarize what we have so far. We know 
that pp i HET “eS holds. From a high-level perspective, most of the previous hybrids 
ensured that corrupted users cannot fool the operator (or PoSes) within tasks that expand the 
transaction database, i.e. essentially within the main tasks IssueWallet, Deposit and Disburse. 

The remaining hybrids from H}? ^ to Hy? 7A largely considers modifications to the utility 
tasks with honest users being of special concern. The final simulator .S?P5*^ needs to provide 
various tags (Ods: Opr rc and cp) to Jape that are output by the main tasks and later re-used in 
the utility tasks. Until now, i.e. up to simulator Br real messages sent by users have been 
used to compile and record real tags (cp. hybrid ne), These have been played back when 
necessary. While little needs to be changed for corrupted users, the final simulator .S?P ec 


must provide these tags for honest users without having access to any messages. mI to 
HE 7 introduce the necessary modifications. 


Lemma 8.17 (Indistinguishability between HT e and Ho 7**) Under the assumptions 


of Theorem 8.2, HI £ ín holds. 


Proor We need to distinguish the same cases as in S?P 5*6, 

If Z9?P5** calls DetectDS with two double-spending tags wy, = (9,t, us), OA. = (q^,t',uj) 
that do not stem from the system, do not match or are otherwise unusable, the hop is perfectly 
indistinguishable, because SEU simply runs the same algorithm as the honest operator in 
the real game. At the bottom line, both calculate skq, := (t—1”)/(uz—uz) mod p and return the 
result. We stress that in both experiments—the real protocol and the ideal functionality—there 
is no guarantee that the returned skq, is even a valid secret key. This follows the garbage-in- 


garbage-out principle. 
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We now consider genuine double-spending tags that have been output by the system before 
and match each other, i.e., they are distinct and have a common fraud-detection ID g. In this 
case SE sec does not recover skq, from the double-spending tags by calculation, but looks up 
the secret key sky that has been recorded in Mess for pid4, and returns z := skqy as a proof 
of guilt. The only way how Z“P"9*“ could p dd between H,? ^^ and HP“ is 
that sky, + skq holds which entails Pky + gi ku or Pky + gi ku, Intuitively, this attack means 
the environment has been able to let a user commit double-spending such that the generated 
double-spending tags do not allow to calculate a valid proof of guilt. 


op- sec 


If the user is honest, the user’s key has been generated by S, and recorded in Jess 


ab initio. In particular, pk, = gi ku holds and the honest user always correctly answers the 
double-spending challenge. Simple math shows that sky, := (t — t’)/(uz — uj) = ((ugskay + 
u) — (usku + u)))/(u5 - u) = ska follows. 

If the user is corrupted, the user's secret key is generated by the environment. In this case, 


skq, is recovered by SE d 


in the scope of Deposit or Disburse and recorded in fissa due 
to the change in hybrid n = ec di uses the same equation during Deposit/Disburse to 
recover skqy as the honest operator uses in DetectDS to recover skq, in the real game. In other 
words, the recovery of the secret key is only brought forward from a belated double-spending 
detection in the real experiment to the point of time when the double-spending actually occurs 
in the simulated experiment. As the same equation is used, skqy = skq, follows trivially, if the 
recovery has succeeded. 

It remains to show, that sk7, is always successfully recovered, i.e. that the test pkq7 gi U (c cp. 
Step 5 in Fig. 8.9 and Step 4 in Fig. 8.13) succeeds. In short, this holds due to the soundness of the 
NIZK and the binding property of C1. Otherwise hybrid H;P ^^^ or hybrid Hj q *** would already 
have aborted with event E1 or E9, resp. More precisely, using Remark 8.8 we conclude that the 
two equations T — pk -U, and T’ = pki -U, with extracted pk, T, T^ and U hold. Moreover, 
T = gi, T' = gi hold and t, t’ as well as uz, u, are known as part of the statement. By equating 
we obtain T pku” =T -pk which yields pk, = Get) = gl uw) = gm 
Lemma 8.18 (Indistinguishability between Hi = 


of Theorem 8.2, HY M = HP e holds. 


and Hr Under the assumptions 


Pnoor VerifyGuilt is a local algorithm and does not send any messages. Hence, Z?P 5** can 
distinguish between HA sec and HE eS if and only if VerifyGuilt returns a different result bit 
for the same input. 

First note, that S7! ^^ still falls back to the real algorithm, if Z^P^** calls VerifyGuilt with 
an input (pid, 7) for a corrupted user and a x which is made-up by Z“P"**, i.e., if the internal 


"d sec 


map f; of simulator S; is undefined (cp. Step 2 in Fig. 4.14). In this case H? 7 is perfectly 
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indistinguishable from Hr In other words, Z?P *** has to call VerifyGuilt for an honest 


user pid,, or for a genuine proof of guilt 7, in order to trigger a distinguishing result bit, if at 


all. 


Also note, that the real code and the ideal functionality are both deterministic. W.l.o.g. 
it therefore suffices to consider first-time invocations of VerifyGuilt for a particular input 
(pid, ,, 77). Under this restriction f; (pid, z) is only defined, if it has been set in the scope of 
Deposit or Disburse (cp. Step 5 in Fig. 8.9 and Step 4 in Fig. 8.13) or in the scope of DetectDS (cp. 
Fig. 4.13). The necessary modifications have been introduced by hybrids prm and m 
resp. However, we can ignore that f,(pid., 2) is solely defined, because VerifyGuilt is invoked 
a second time (cp. Step 4 in Fig. 4.14). 

We discuss both cases for a different outcome separately. 

VerifyGuilt(pid,,,) returns NOK in He (real code) but OK in mre (ideal functionality): 
VerifyGuilt(pid7,,) only returns OK in HUS fr(pidq;,) = OK has been defined 
by Deposit, Disburse or DetectDS. In all three cases, the simulator provides a proof of 
guilt x = sky with (pk, sku) = freys(Pid4,)- We already know from the assertions 
made in the proof of Lemma 8.17 that pk,, = giku holds for those key pairs recorded in 
freys: However, if pkq; = gu holds, then the real code of VerifyGuilt in HI returns 
OK (cp. Fig. 7.24) which contradicts the initial assumption. We conclude, this case can 
never occur. 

VerifyGuilt(pid,,,) returns OK in HU (real code) but NOK in da (ideal functionality): 
As Verify Guilt running the real code returns OK, pkg, = gf holds. As VerifyGuilt in 
HY 7 returns NOK, we conclude that fr(pidq, 7) is undefined and using the introduc- 
tory remarks this implies that the user with pid, is honest. (Remember: For an undefined 
fa(pidqp 7) and a corrupted user, H7? ^^^ falls back to the real code.) If f; (pid, zr) was 
defined in H? "SC then it had to be defined as OK, because we excluded repeated invoca- 


tions of VerifyGuilt and Deposit or Disburse only define f; in positive cases. The latter 
op-sec 
18 

also yields that the user under consideration does not commit double-spending or oth- 


immediately contradicts, that VerifyGuilt returns NOK in H . The same observation 
erwise the simulator would have defined f;(pid,,, 2) = OK in the scope of Deposit or 


Disburse. 


o op-sec 


In summary, VerifyGuilt(pid, ,, 1) returns OK in HT ^ but NOK in Hj? ^. if and only if 
there is an environment Z?P5** that comes up with a correct proof of guilt x = sk, for 
a honest user without letting this user commit double-spending. This immediately yields 


an efficient adversary 8 against the DLOG assumption. 
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Externally, 8 gets a group element g € G; as its input. Internally, 8 runs Z?P 5** in its 
head and plays the role of the simulator and all honest parties. 8 guesses the honest user 
for that Z?P *** eventually calls the distinguishing VerifyGuilt. When 8 has to internally 
provide pk, in the scope of RegisterUser, it uses pk,, = g. Note, that £ does not need 
to know sk4, for a successful simulation. As the user is honest, all PoS and operator are 
honest, too? Hence, for this particular user no messages need to be simulated. When 
JP'S calls VerifyGuilt with a correct x := skqy, B outputs skqy as the DLOG. " 


Lemma 8.19 (Indistinguishability between Hr e and RET 7**) Under the assumptions 


of Theorem 8.2, HE £ HE holds. 


Pnoor This hop is perfectly indistinguishable from the environment’s perspective as the 
modifications made by hybrid HS 7 do not change the output. Note that operator and dispute 
resolver are both honest. Due to the correctness of ENC1 the ciphertext wp; determines a unique 
message (for a fix key pair pk pp, skpg). Hence, the originally recorded wallet ID A := fa o) 


equals the one that «yj decrypts to. " 


Lemma 8.20 (Indistinguishability between Hj) ^ and Hj? °°) Under the assumptions 
of Theorem 8.2, Hy £ E holds. 


Pnoor The task RecalculateBalance is an algorithm that locally executed by the operator 


and the operator is honest. The hop is perfectly indistinguishable from the environment's 


perspective as the modifications made by hybrid Ha see do not change the output using the 
same argument as for the previous hop. The set of recalculation tags Q,, = QEU" y Qfake is 


partitioned into two disjoint subsets. Due to the correctness of ENC2 looking up the original 


recorded cleartext J^ for a wee e QBN” yields the same result as actual decryption. 
The treatment of “fake is not changed at all. " 


Lemma 8.21 (Indistinguishability between HE "and Hr 7**) Under the assumptions 


of Theorem 8.2, ne £ Ha holds. 


Pnoor Assume there is an environment ZP" that triggers event E10 with non-negligible 
probability. This immediately yields an efficient adversary 8 against the EUF-CMA security of 
SIG. Internally, 8 runs Z?P5** in its head and plays the role of the simulator and all honest 
parties. Externally, 8 plays the EUF-CMA security game with a challenger C and a signing 


^ Thisis a consequence of the considered corruption model. In the case of operator security, corrupted PoSes are 


only admissible, if all users are corrupted. 
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oracle OSE st B needs to guess the honest PoS with pid, for which the environment Z?P *** 
eventually forges a signature while it plays a corrupted user who tries to prove its participation 
in a transaction with this particular PoS towards an honest violation enforcer. When the PoS 
with pid, registers itself in the scope of RegisterPOS and 8 playing a“ needs to provide 
pkp = (pkt, pkp» pẹ) it embeds the external challenge public key as pk . Whenever 8 


8 * needs to issue a signature with respect to pkẸP, it uses its external 


en the role of S, 


EUF-CMA oracle OS'S, pp. When the event E10 occurs, 8 extracts ok, 
pkp skp 


Ypp and outputs the forgery. N.b., the Cp, has never been signed with respect to pa by 


x. from Opp and Op p from 


assumption as otherwise Jii would have been defined for the pair c, Ypp and the event E10 


would not have been triggered. " 


Lemma 8.22 (Indistinguishability between BER er 


of Theorem 8.2, Hy ae 24 *** holds. 


and Br seo) Under the assumptions 


Proof Assume there is an environment Z/?P *** that triggers event E11 with non-negligible 
probability. This immediately yields an efficient adversary 8 against the binding property of 
C2. Internally, 8 runs Z?P*** in its head and plays the role of the simulator and all honest 
parties. When the event E11 occurs, B extracts c ok, from op, gathers the current public key 
pk, of the user it currently interacts with and the provided decommitment d), ky? looks up the 
original public key pk, and original decommitment dx. that have been recorded by fpp and 
outputs (ep. dy, pkq,) and (pi, dX pk). Note, pk,, + pkq, holds and both openings are 


valid by assumption. " 


Lemma 8.23 (Indistinguishability between IET e and HP 7**) Under the assumptions 
of Theorem 8.2, HE see E "d *** holds. 


Proor At the bottom line this hop only changes what part of code is executed by which entity, 
ie. the hop is perfectly indistinguishable from the perspective of Z/?P 5e, 

This is obvious in the case of an honest user and a corrupted violation enforcer. Honest 
users always send the true decommitment information that originally belongs to their prove- 
participation tag and they only do so for prove-participation tags that are their own ones. This 
is exactly what the simulator does on behalf of the dummy user. 

In case of a corrupted user and an honest violation enforcer the only way for Z/?P 5*6 to 
distinguish between d sec and ROT sec is to make the honest violation enforcer output a 
different result bit. In summary, this is impossible due to the sanity checks that have been 
introduced in H5 d see and He “Se The detailed argument considers the branches of the program 


flow individually. If the signature is invalid, i.e. SIG.Vfy(pkyP, ) = 0 holds, or the 


Onn, C. k 
pp» Cpk,, 
decommitment fails, i.e. C2.Open(ers(?),, pk Cpk doky) = 0 holds, the simulator calls the 
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ideal functionality with input @pp = 1 (cp. Step 3f in Fig. 8.17) and the ideal functionality always 
outputs result = NOK to VE. The real code also returns result = NOK under the same condition. 
We now consider the case that the simulator runs the ideal code with an input (pp + L. Step 3i 


in Fig. 8.17 is only reached, if the conditions of Steps 3f to 3h failed all. Formally, this means 


al (Upp Sly Vfy(pkbP, Opp: Ck.) =0v Open(ers ns pkap Cok? pk) = 0) 
v (Vip = LA pid, € FD) (8.27) 


v (Open(ers ns pkap Cpk dy.) =11pk + pku)) 


holds. After simplification (note that some parts cancel out due to inverse conditions on Open) 


Yop * L^ Vfy(pkEP opp. Cok.) =1A Openers an pkap Cpky pk, )) =1 (8.20) 
^ pku = pku ^ (Jp + Lv pidp € PIDcorr) 


remains. We further note, that pk,, = pk, implies c + L, or inversely stated, if wp, was 
invalid, then pk, would be undefined, too. Hence, the last predicate inside the or-bracket is 
irrelevant and can be dropped. Also, we exploit that pk, = pk, can equivalently be substituted 
by pid, = pid;, and we finally obtain 


Yop ELN Vfy (pk, opp» Cok, =1A Open(crsQ2),, pkap Ck. p Apka) =1 nom 


^ Yp + LA pida, = pid;, 


The first line of this expression is exactly the condition under that the real code returns 


result = OK, the last line is the condition under that the ideal functionality returns OK. " 


Lemma 8.24 (Indistinguishability between HT see and i 7*^) Under the assumptions 
of Theorem 8.2, HI. ES 7 holds. 


Pnoor In this hop all encryptions y; of wallet IDs A are replaced by encryptions of a 1-vector 
for all honest users. This does not change the output of an honest operator, as H7? — has 
eliminated their decryption. 

We further split this hop into a sequence of sub-hybrids, with each sub-hybrid replacing a 
single encryption in reverse order of appearance. Assume Z?P 5** can distinguish between 
HIE sec and HC with non-negligible advantage. This yields an efficient adversary 8 against 
the IND-CCA security of the encryption scheme ENC1. Internally, 8 runs Z?P5** and plays 


the role of all parties and the simulator for Z?P5**, Externally, 8 plays the IND-CCA security 


NC1 


. . E 
game with a challenger C and a decryption oracle cr E 


. When $—playing the role of 
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the simulator—needs to provide the public key in the scope of RegisterDR, it embeds the 
challenge key pk pp. B needs to guess the index of the sub-hybrid that causes a non-negligible 
difference, i.e., B needs to guess which (user) wallet causes distinguishability. For the first 
(i — 1) invocations of IssueWallet, 8 encrypts the true seed, in the ith invocation 8 embeds the 
external challenge and 8 encrypts a 1-vector for the remaining invocations of IssueWallet. If 
Z?P'**€ invokes the task BlacklistWallet between O and VE and 8 needs to restore the wallet 
ID, the following two cases may occur: (1) The presented blacklisting tag œ is genuine. In this 
case B uses the lookup table fa, 1 that has been edified in ne to recover the original wallet 
ID A and thereby the correct set of fraud-detection IDs (cp. hybrid Hr **^). (2) The presented 
blacklisting tag œ is a fake. In this case B uses its decryption oracle ONC, to restore the 


wallet ID A and to create a set of fraud-detection IDs. 8 outputs whatever Z?P5*^ outputs. m 


Lemma 8.25 (Indistinguishability between H7? ^^^ and H52 ^^^) Under the assumptions 
of Theorem 8.2, H5» ^ = = 56. holds. 


Pnoor This hop is perfectly indistinguishable. As long as no double-spending occurs, the user 
chooses a fresh u; in every transaction and thus a single point (ug, t) is information-theoretically 


independent from sk,. " 


Lemma 8.26 (Indistinguishability between HE e and HE 7**) Under the assumptions 
of Theorem 8.2, He m ae holds. 


Pnoor This hop only replaces the encryption of recalculation tags, if the operator is honest. If 
the operator is corrupted, the hop only changes what part ofthe code are executed by which 
entity and the hop is perfectly indistinguishable. 

If there is an environment ZP“ that can efficiently distinguish with non-negligible advan- 
tage this yields an adversary B against the IND-CCA security of ENC2. The proof is analogous 
to the proof of Lemma 8.24, but for the operator instead of the violation enforcer and blacklisting 
tags replaced by recalculation tags. 

Externally, $ plays the IND-CCA security game with a challenger C and a decryption oracle 
Ona, spen When $—playing the role of the simulator—needs to provide the public key 
pko = (pk, pk k? q ‚DER, pko sig pk enc) in the scope of RegisterOp, it embeds the challenge 


rc,enc 


key pkg’ 


ie., B needs to guess which recalculation tag causes distinguishability. For the first (i — 1) 


.B iab to guess the index ofthe sub-hybrid that causes a non-negligible difference, 


invocations of Deposit and Disburse, 8 encrypts a true recalculation tag, in the it? invocation 
B embeds the external challenge and $ encrypts an arbitrary, but fixed value for the remaining 
invocations of Deposit and Disburse. If Z?P'5*€ invokes the task RecalculateBalance for O, the 


following two cases may occur: (1) The presented recalculation tag «yj is genuine. In this case 
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8 uses the simulated transaction database TRDB that has been edified in E to recover the 


op-sec 


original values (s, p, pid, p) (cp. hybrid H55  ). (2) The presented recalculation tag «y; is a 


fake. In this case 8 uses its decryption oracle OPEN che „geene fo restore the necessary values. 8 
o ko 


outputs whatever Z?P'5*€ outputs. a 


Lemma 8.27 (Indistinguishability between Ho? ^^^ and H5? ^^^) Under the assumptions 
8 y 26 27 P 
of Theorem 8.2, HL £ HUS holds. 
Pnoor In this hop the simulator SS?“ sends simulated commitments c,, as prove-participa- 
p 27 pk P P P 
tion tags «yy for honest user. In case the violation enforcer is corrupted, simulator se 7 equiv- 
ocates these commitments to the correct pk, on demand, when Z?P'*** calls ProveParticipation 
for an honest user and an affected w,,. If Z9?P'5** has a non-negligible advantage to distinguish 
pp Bug & £ 
between ROT © and HT © then an efficient adversary 8 can be constructed against the 
hiding property and equivocality of C2. Again, this proof proceeds in a series of sub-hybrids 
8 property q y & P P y 


with each sub-hybrid replacing a single Coku by a simulated commitment. " 


Taking all the aforementioned statements together, Theorem 8.2 from the beginning of this 


section follows. For the sake of formal completeness, we recall it again. 
Theorem 8.2 (Operator Security) Under the assumptions of Theorem 8.1 


Tn ws 
Tpsc ™ DUC Fape (8.3) 


holds under static corruption of 
(1) a subset of users, or 
(2) all users and a subset of PoSes, operator and violation enforcer. 


Proor A direct consequence of Lemmas 8.4 to 8.27. " 


8.4 Proof of User Security and Privacy 


In this section we show the remaining half of Theorem 8.1 by proofing the the following 


theorem. 
Theorem 8.28 (User Security and Privacy) Under the assumptions of Theorem 8.1 


Fers-Fop-Fn 
Tpsc ™ SUC Fape (8.32) 


holds under static corruption of 
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Simulator Ss seS 
Setup: (1) Run a modified version of the algorithm crs — Setup(1”) with 
(a) erst < C2.Setup being replaced by (ers). tdeqcom) + C2.SetupSim, 
(b) crs < C4.Setup being replaced by (os. tdextcom) * C4.SetupExt, 
and 
(c) crspox - POK.Setup being replaced by (crsyo4; td spo) = POK.SetupSim. 


(2) Record crs, tdegcom» tdextcom> and tdsnok- 
(3) Set Mes? : PID > (0, 1}* to the “empty” map. 


(4) Set ds Npp > Pop x {0, 1}* to the “empty” map. 


The internal copy of Fsg: Sm. © runs an internal instance of 75, in its head and 
proceeds as follows: 


(1) Upon receiving input of the form (establish-session,...), (accept,...), 
(send,...) or (close,... ) from Z "ser sec for Fmsg in the name of a corrupted 
party, Says. forwards this input to its internal instance of Fmsg in the name 
of the same party. 

(2) Upon receiving output of the form (establishing-session,...), (accepted, ...), 
(sent, ...) or (closed,...) from its internal instance of Fmsg for a corrupted 
party, Sy 5** forwards this output to ZS S°°, 

(3) Upon receiving leakage from its internal copy instance of 75, for an 
adversary, Spy." forwards this leakage to 5€ 5** as the real dummy 
adversary would do. 

(4) Upon receiving output of the form (establishing-session,...), (accepted, ...), 
(sent, ...) or (closed,...) from its internal instance of Fmsg for an honest party, 


Sme handles this output internally as desribed below in detail. 


Figure 8.19: The Simulator for User Security and Privacy 


(1) a subset of PoSes, operator and violation enforcer, or 
(2) all PoSes, operator and violation enforcer as well as a subset of users. 


The definition of the UC-simulator Sapa. for Theorem 8.28 can be found in Figs. 8.19 
to 8.34. Please note that while the real protocol psc lives in the (Fors. £55. Fmsg)-model, the 
ideal functionality 7;,, has no CRS. The CRS is simulated, providing Syst" 5** with a lever to 
simulate the ZK proofs P1, P2, and P3, to equivocate C2, and to extract C4. 

As before, we define a sequence of hybrid experiments H75*'5*€ together with simulators 
S;5*"5** and protocols 775*"5** such that the first hybrid H, is identical to the real experiment 


and the last protocol 7, is identical to the ideal experiment. The general proof strategy is 
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user-sec 


Simulator Sapo. 


RegisterDR (for honest dispute resolver): Upon receiving leakage 


(registering dr, pid pp) from fap, and if Áieys (pid pp) is undefined, run 
(pk pp» skpg) + RegisterDR(crs), and append pid pp > (pk pp, skpg) to Juss 


RegisterOp (for honest operator): Upon receiving leakage (registering op, pido, ag) 


from fpc and if Freys(Pid o) is undefined, run 
(Pko sko, certo) <— RegisterOp(crs, ag), and append pido > (pko sko, certo) to 


fi keys: 


RegisterOp (for corrupted operator): Upon receiving input (register, pko) from 


ZU for Fpp in the name of O with PID pido, and if Áieys (pido) is undefined, 
call fpc with input (register) in the name of O with PID pido, ignore the 
subsequent leak (registering op, pido) from %p. and append pid, > (pkg, 1, 1) 


to Jkeys^ 


RegisterPOS (for honest PoS): Upon receiving leakage (registering pos, pid) from 


fap, and if hreys(Pidy) is undefined, run (pkp, skp) — RegisterPOS(crs), and 
append pid, +> (pkg, skp, L) to feys 


RegisterPOS (for corrupted PoS): Upon receiving input (register, pkp) from ZS 5c 


for yy in the name of P with PID pid, and if hreys(Pidg) is undefined, call Faye 
with input (register) in the name of P with PID pid,, ignore the subsequent leak 
(registering pos, pid) from fpc and append pid, > (pkp, L, L) to Jess" 


RegisterUser (for honest user): Upon receiving leakage (registering user, pid,,) from 


fap, and if freys(Pidg,) is undefined, run (pk, , skqy) — RegisterUser(crs), and 
append pid,, > (pku skqy) to dies 


a 


A corrupted operator essentially has two options: It can either register “some” public key at the bulletin 
board or not. (N.b., the public key does not need to be honestly generated.) If it registers its public key, 
then it is regarded as registered from the perspective of the real protocols. Hence, the simulator must also 
register the operator with fpo otherwise Fipe would subsequently abort, but the real protocols do not. 
Corrupted PoSes essentially have two options: They can either register “some” public key at the bulletin 
board or not. (N.b., the public key does not need to be honestly generated.) If they register their public keys, 
then they are regarded as registered from the perspective of the real protocols. Hence, the simulator must 
also register the PoSes with Fipo otherwise Fipe would subsequently abort, but the real protocols do not. 
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Figure 8.20: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 


8.4 Proof of User Security and Privacy 


1 user-sec 
Simulator S727 


CertifyPOS (for honest operator and honest PoS): Upon receiving leakage 
(certifying pos, pid, ap) from Fape ++ 


(1) Set (pkg, sko» certo) = fie (pido) and (pk, skp, cert) = fieys(Pidp). 
(2) Generate cert := (pkp, ap, of") with apt — SIG.Sign(skG",, (pk, ap)) 
faithfully. 


(3) Re-define fe~ (pid) := (pko, skp, cert») and let 744. continue. 
keys pid DK, SKp p apc 


CertifyPOS (for honest operator and corrupted PoS): (1) Upon receiving output 
(establishing-session, ssid, pidp, certify_pos) from e for O, call Tape 
with input (certify_pos) in the name of P with pid,. 

(2) Upon receiving leakage (certifying_pos, pid,, ap) from Fape ... 


(a) Set (pko, sko, certo) = hreys(Pidg) and (pkp, L, cert) = Jes (pid p). 
(b) Call a with input (accept, ssid) in the name of O. 
(3) Upon being requested by Z"5*S€¢ to provide the 1* message from O to P ... 


cert 


(a) Generate certp :— (pkp, ap, og") with og"! — SIG.Sign(sko" , (pkp, ap)) 
faithfully. 
(b) Redefine Jkeys (pid) := (pkp, L, certo). 
(c) Call mnm with input (send, ssid, cert?) in the name of O for the ı* 
message from O to P. 
(4) Upon receiving output (closed, ssid) from Gane for O, let fpc deliver its 
output to O. 
(5) Upon receiving output (certified_pos,ap) from fpc for P, do nothing. 


^ N.b.: These assignments exist. An honest operator or honest PoS, resp., must have called RegisterOp and 
RegisterPOS previously, otherwise fpc would already have aborted. 

N.b.: These assignments exist. An honest operator must have called RegisterOp otherwise Fipe would already 
have aborted. The malicious PoS has either either registered its public key at the bulletin-board Fpp or not. If it 
had not registered at the bulletin-board, then the real protocol would have aborted at the operator's side. The 
ideal functionality 7). would also have aborted and never leaked the message (certifying pos, pid,, ap) in 
the first place. Contrary, if PoS had registed at the bulletin-board, the real protocol does not abort. However, 
in this case Sigo. would have (silently) defined heys(pidp) and registered the PoS with Apc and thus Ape 
does not abort neither. 


Figure 8.21: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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1 user-sec 
Simulator S777 


CertifyPOS (for corrupted operator and honest PoS): (1) Upon receiving output 
(certifying pos, pid) from fpc for O, call $E with input 
(establish-session, ident, pido, certify pos)in the name of P with pid,,. 

(2) Upon receiving output (accepted, ssid) from Fane for P, do nothing. 
(3) Upon receiving output (sent, ssid, certp) from fum for P, ... 
(a) Set (pkg, L, 1) = hreys(Pidg) and (pkg, skp, certh ™) = hreys(Pidp) a 
(b) Parse ap and 0£°" from certo. 
(c) Parse pk from pk». 
(d) If SIC.Vfy (pk, p. (pkp, ap)) = 0, set ap := Land certp := 1. 
(e) Redefine hreys(Pidy) := (pkg, skp, certp). 
(f) Call Tape with input (certifying_pos, ap) in the name of O and ignore 
the subsequent leak (certifying_pos, pidp, 1) from Faye. 
(4) Upon receiving output (certified_pos) from fpc for O, call Fae with input 


(close, ssid) in the name of P. 


CertifyPOS (for corrupted operator and corrupted PoS): (nothing to do as ZUSersec 
plays both parties) 


^ See previous footnote with inverse roles. 


Figure 8.22: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 


Simulator S75 5** (cont.) 


IssueWallet (for honest operator and honest user): (1) Upon receiving leakage 
(issuing wallet) from fpc and being asked to provide ay ... 


(a) A” È Zy. 2 
(b) Jy — ENC1.Enc(pk pp, (1, ...,1)). 


(c) Set Op] *= A”, Jy). 
(d) Provide cy; to Fapc- 


Figure 8.23: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator 5757 5** (cont.) 


IssueWallet (for corrupted operator and honest user): (1) Upon receiving output 


(issuing wallet, pid,,) from fpc for O, call mse with input 


(establish-session, ident, pid y, issue wallet)in the name of U with pid, ;. 
(2) Upon receiving output (accepted, ssid) from Fane for U, ... 
(a) Set (pkqp sku) = fiy, (pida) and (pk pp, skpg) = Fkeys(Pidpr)-“ 
(b) (c; d; wid) e C3. Commit(crs®),,, 0). 
(c) Call Fsg with input (send, ssid, c/ . ,) in the name of U for the 1* message 
from U to O. 


(3) Upon receiving output (sent, ssid, (certo, aqp Cr, A”)) from b for U, ... 


(a) Parse (pk ur’, a0; agit) = :— certo. 
(b) If SIG. VEy(pk5", age, (pk? 4, ag) = 0 abort. 
(©) A” = gi" 


d) s" — C4.Extract(crs’),, idayicsrna Car): 
(e) Call %p. with input (issue_wallet, aq) in the name of O with pido. 


~ 


(4) Upon receiving leakage (issuing_wallet, s, aq) from Fape -- 


(a) s' := sl, +2 


(b) Jg; = ENC1.Enc(pk pp, (1, ... , 1)). 

(c) (cg, dex) <— Cl. Commit (ori, (0, 0)). 

(d) (c Odo dapa) < CI. Commit(erstom (0, 0, 0, 0)). 

(e) stmnt := (pkar Pk pp: Yow CB: Cupo € an A” A"). 

(f) z — P1.ProveSim(crspoko td sok: stmnt). 

(g) Call exe with input (send, ssid, (s’, Vj. Cay Cupd» z)) in the name of U for 


the 2"* message from U to O. 


(5) Upon receiving output (sent, ssid, (s”, die, Og, Supd)) from Ge for U, let 
Fape continue. 


^ N.b. These assignments exist. An honest user or honest dispute resolver, resp., must have called RegisterUser 
and RegisterDR previously, otherwise fpc would already have aborted. 


Figure 8.24: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator S75 5** (cont.) 
IssueWallet (for corrupted operator and honest user, continued): (6) Upon receiving 
leakage (issuing wallet) from 9%). and being asked to provide «y ... 
(a) Set «yj = (A", Vp). 
(b) Provide cy; to Fape- 
(7) Upon receiving output (issued wallet, s, coy) from Fape for O ... 


~ 


a) If C4.Open(crs),,, S”, Chers Ager) = 0, let Fay abort. 


(b) Create real token r faithfully. 
(c) If VerifyWallet(pko, Pkap T) = 0, let Fape abort. 
(d) Let fpc deliver its output to U. 


Figure 8.25: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 


explained in Section 8.2 and is the same as in Section 8.3. We stress that some of the hybrids 
are nearly identical to those in Section 8.3. We proceed by giving concrete definitions of all 
hybrids HUSersec, 


Hybrid Hy°°"°°° (The real experiment) The hybrid Hjy**'5** is defined as 
Hysersee = EXEC „user-sec, guser-sec Zuser-sec( 17) (8.33) 


with SSe :— D being identical to the dummy adversary and z5€'5€€ :— mpsc. Hence, 


Hj**'5** denotes the real experiment. 


Hybrid H7s**s** (Fake setup) In hybrid Hy'*"S°° we modify S}8*S such that Cr$yoy is gen- 
erated by SetupSim, es), is generated by C2.SetupSim and crs), is generated by C4.SetupExt. 
Se initializes Ties and Jop as “empty” maps. Additionally, SY9°%-sec invokes an internal 
instance of 75555 instead of the external instance 7,,, and reroutes all input/output accordingly. 
All calls to the bulletin-board Fpp are handled internally by .$15€75*^ using the map Tees 


Hybrid H7*%"*“ (Simulate honest keys) Hybrid H55*'5** replaces the code in the tasks 
RegisterDR, RegisterOp, RegisterPOS and RegisterUser of the protocol 75€" 5** such that the 
simulator .S25€'5€€ is asked for the keys instead. Also, if corrupted PoSes or users try to register 
a (maliciously) generated public key at the bulletin-board Fpp, then .S75€75** calls RegisterPOS 
or RegisterUser, resp., in order to simultaneously register the parties for Fipe- Sy" defines 
keys appropriately. This equals the method in which the keys are generated in the ideal 


experiment. 
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Simulator 5757 *** (cont.) 
Deposit (for honest PoS and honest user): (1) Upon reveiving leakage (depositing, 
pid, QU) from fpc: iss 
a) Set (pk, sku) := hreys(Pidq))." 
b) Pick u È Zp. 
c) Check if 3 wh = (y’,t’,us) € Ay s.t. ag, + L and uz + uz hold.’ 
d) If yes, t :— t’ + skqy(uz — us). 
(e) Provide x = skq, to Fape- 


en 


~ 


Ga 


(2) Upon receiving leakage (depositing, s, 9, pid) or (depositing, s, Q, pid,, p) 

from fpc and being asked to provide (oq. Orc, pp), ... 
(a) Set (pkg, 1, 1) = Fkeys(Pido)- 
(b) Parse pko from pko. 
(c) Parse pk/skp and pkEP/sk?P from pkp/skp. 

PKp PKp /SKp DKpl skp 
(d) If (t, uz) is not yet defined, pick (t, uz) & 724 

y P p 


(e) Set wg, := (Q, t, uz). 
(£) If p has not been leaked (i.e., operator is honest): 


(i) Set Y. to an arbitrary value from the correct space.‘ 

Else (i.e., operator is corrupted): 

(i) Set o, + SIG.Sign(skg, (s, p, gP)). 

(ii) Set Yre = (8,9, p. pk. Oro). 
(g) Set 4, - ENC2.Enc(pk5 ^, Yro). 
(h) Run (pk, Apka) < C2.CommitSim(crs),, 3 
(i) Assign op) = SIG.Sign(skp egy... 
(j) Set Opp `= Cpky and Yop = (KT, Opp: dp. .) 


(k) Define festa) = (Wpp> 81): 
(1) Provide (was, c, @pp) to Fape- 


N.b.: This assignment exists. An honest user must have called RegisterUser previously, otherwise pe would 
already have aborted. 

N.b., even if the user commits double-spending no *useful", previous double-spending tag may exist in Yo 
if the user only did so at corrupted PoSes that undermine double-spending detection. 

N.b.: These assignments exist. The operator/PoS must have called RegisterOp/RegisterPOS previously, 
otherwise fip: would already have aborted. 

Step 1d is only executed, if the user commits double-spending. 

* The hidden recalculation tag is of the form Yio = (s, 9. p, Pk» Orc) € Gy X Gy x Zp x (G? x G3) x (G2 x G1), e.g» 
Wee = (1,1,0, 1, 1, 1, 1, 1, 1, 1, 1) would be a good choice. 


Figure 8.26: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator S75 5** (cont.) 

Deposit (for corrupted PoS and honest user): (1) Upon receiving output (depositing) 
from fa. for P, call $7 with input (establish-session, anon, pidp, deposit) 
in the name of some imaginary user U with a randomly chosen pide. 

(2) Upon receiving output (accepted, ssid) from $355 for U, do nothing. 
(3) Upon receiving output (sent, ssid, (ug, cer, certp)) from Fsg for U, ... 
(a) Set (Pkg) = fe (pido) 
(b) Parse (pkp. ap, op") := certo. 
(c) Parse pke d and pk? from pkp. 
(d) If SIG.Vfy(pkG o£", (pkp ap)) = 0, let Faye and Fin abort. 
(e) s" — C4.Extract(crsc),,, cl, 5 
(f) Call %p. with input (deposit, 2)^in the name of P with pid,. 
(4) Upon receiving leakage (depositing, s, a4/) from fipo» let Fap¢ continue. 
(5) Upon reveiving leakage (depositing, pid, a) from fae, ... 
(a) Set (pku ska) = Fkeys(Pidq)- 
(b) Check if 3 0%, = (o^, t^, us) € m s.t. o^. * L and uy + uz hold.‘ 
(c) If yes, t := t' + skq(ug — u5). 
(d) Provide z := skq, to fapc- 


N.b.: This assignment exists. An operator must have called RegisterOp previously, otherwise Fipe would 
already have aborted. 

Use empty set as blacklist. 

N.b.: This assignment exists. An honest user must have called RegisterUser previously, otherwise Jipe would 
already have aborted. 

N.b., even if the user commits double-spending no “useful”, previous double-spending tag may exist in Ys 
if the user only did so at corrupted PoSes that undermine double-spending detection. 


Figure 8.27: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator 5757 **^ (cont.) 
Deposit (for corrupted PoS and honest user, continued): (6) Upon receiving output 
(depositing, s, aqy, ab.) from Tape for P ... 
(a) s':— set, 
(b) Run (Cok ar Ípku )< C2. CommitSim(crs®),,). 


(c) (c; Cip "p — CI. Commit(eriim, (0 0, 0, 0)). 


(d) If t is not yet defined, pick t E. Zp.“ 


cert 


(e) stmnt := (pko: pko , Q, aqp ab ev » Cpk p Cape? t, uz). 
(f) z < P2. -ProveSim(crspok, td joke stmnt). 
(g) Call insg with input (send, ssid, (s’, 1, 9, aqy, ab ev Cok apd t)) in the 
name of U. 
(7) Upon receiving output (sent, ssid, (s”, da, Cupd dpa» upd» P: Opp) from run 
for U, ... 


(a) dupa = d 


L4 
upd d 


rad 
(b) If C1.Open(ers),,. (1, gf, 1, 81); Cupa dapa) = 0 let Fape abort. 
(c) If SIG. Vfy(pkz?". oupa: (Cupd» s)) = 0, let Tape abort. 
(d) If SIG.Vfy(pkPP, opp, pk) = 0, let Tape abort. 
(e) Call Zape with input (depositing, p) in the name of P. 
(8) Upon receiving leakage (depositing, s,, pidp) or (depositing, s, p, pid, p) 
from fpc and being asked to provide (was, Orc, pp), ... 
(a) Set wg, := (p, t, uz). 
(b) Set Yre to an arbitrary value from the correct space.” 
(c) Set wre E ENC2. Enc(pko: at mI 
(d) Set pp : E pk and Ypp = (PE, Opp» dp, ). 
(e) Define Sop pp) = Upp: E1)- 
(f) Provide (cx, Orc, Opp) tO Fape- 
(9) Upon receiving output (deposited, qs: Orc, opp) from Fane for P, let Faye 
deliver its output to U. 


^ Step 5c is only executed, if the user commits double-spending. 
^ The hidden recalculation tag is of the form Yre = (S, 9, p, pk. Ore) € Gy x Gy x Z x (G2 x G3) x (G2 x G1), e-g., 
g PP, PKp p 1 2 2 8 
Vee = (1, 1,0, 1, 1, 1,1, 1,1, 1, 1) would be a good choice. 


Figure 8.28: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator S75 5** (cont.) 


Disburse (for honest operator and honest user): (1) Upon reveiving leakage 


(disbursing, pid, ,, QU) from Fape; ... 

(a) Set (pk, ska) = fiy (pide). 

(b) Pick u È Z}. 

(c) Check if 3 o. = (9, t’, ug) € Ay s.t. o^. * L and uz + uz hold." 
(d) If yes, t := t’ + skqi(u5 — u5). 

(e) Provide x := sk, to 5. 


(2) Upon receiving leakage (disbursing, s, 9) from 7). and being asked to 


provide (c, Wrc), ... 
rc,enc 


(a) Set (pkg, L, L) = hreys(Pidg) and parse pko’ from pk.” 
(b) If (t, uz) is not yet defined, pick (t, uz) R Z24 
2 y P 2 p 

(c) Set wg, := (p, t, uz). 
(d) Set Ye to an arbitrary value from the correct space.‘ 

re y P 
(e) Set c, — ENC2.Enc(pk5 Yo). 
(f) Provide (cx, cc) to Fape- 


N.b.: This assignment exists. An honest user must have called RegisterUser previously, otherwise fpc would 
already have aborted. 

N.b., even if the user commits double-spending no “useful”, previous double-spending tag may exist in [o 
ifthe user only did so at corrupted PoSes that undermine double-spending detection. 

N.b.: This assignment exists. The operator must have called RegisterOp previously, otherwise Fipe would 
already have aborted. 

Step 1d is only executed, if the user commits double-spending. 

The hidden recalculation tag is of the form Ye = (8,9, p. pkp» Orc) € G1 x Gy x Zy x (G? x G3) x (G2 x Gy), e.g. 
Ye = (1, 1,0, 1, 1, 1, 1, 1, 1, 1, 1) would be a good choice. 
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Figure 8.29: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 


8.4 Proof of User Security and Privacy 


Disburse (for corrupted operator and honest user): (1) Upon receiving output 


Simulator 5757 5** (cont.) 


(disbursing, pid,,) from Tape for O, ... 


(a) Set (pkg, 1, 1) := Áieys(pid o)" 
(b) Call ud with input (establish-session, ident, pido, deposit) in the 
name of U with pid, 
(2) Upon receiving output (accepted, ssid) from ee for U, do nothing. 
(3) Upon receiving output (sent, ssid, uz) from Fae for U, call fpc with input 
(disbursing) in the name of O. 
(4) Upon reveiving leakage (disbursing, pid, y, Qf) from fipo ... 


(a) Set (pk, ,, sku) = freys(Pidg).’ 
(b) Check if 3 wh = (p”,t”,us) € Qr s.t. 04, HL and uz + uz hold." 
(c) If yes, t = t’ + skqy(uz — uz). 
(d) Provide x := sku to Fane. 
(5) Upon receiving leakage (disbursing, s, 9) from Fap. and being asked to 
provide (wgs: Ore) --- 


(a) If t is not yet defined, pick t è Zu. 
(b) Set wg, := (p,t, uz). 
(c) Set Y, to an arbitrary value from the correct space.” 
(d) Set wre - ENC2.Enc(pk5 ^^, Yro). 
(e) Provide (wg, cc) to Fape- 
(6) Upon receiving output (disbursed, Pill, wgs, @rc) from Fape for O ... 


cert pill 


(a) stmnt := (pkan pkB*, pk% 0,8) tu). 
(b) x — P3.ProveSim(crs tds ook stmnt). 


(c) Call mp with input (send, ssid, (7, y, pill +)) in the name of U. 


pole 


(7) Upon receiving output (sent, ssid, OK) from ig for U, let Zap. deliver its 
output to U. 


N.b.: These assignments exist. The operator, must have called RegisterOp previously, otherwise 7;,, would 
already have aborted. 

N.b.: This assignment exists. An honest user must have called RegisterUser previously, otherwise pe would 
already have aborted. 

N.b., even if the user commits double-spending no *useful", previous double-spending tag may exist in [o 
if the user only did so at corrupted PoSes that undermine double-spending detection. 

Step 4c is only executed, if the user commits double-spending. 

The hidden recalculation tag is of the form Yre = (s. p, p. pk. oy.) € Gy x G1 x Zp x (G? x G3) x (G2 x G1), eg. 
Vee = (1,1,0,1,1,1,1, 1, 1, 1, 1) would be a good choice. 


Figure 8.30: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator S78" *** (cont.) 
DetectDS (for honest operator) (1) Upon receiving leakage (detecting_ds, wgs, 04.) 
from Fape and being asked to provide (pid, z, result), ... 
(a) Parse (p, t, uz) = wg, and (9, t’,u5) = 0%. 
(b) If p = g’ and uz + uj: 
(i) Set sk, = (t — t^)/(u5 — uz) mod p. 
(ii) Set pk, = gi". 
Else, set (pk, sky) = CL, 1). 
(c) Set pid, = fieys(PKap ydf ls is not defined for pk, , set pid, = L. 
(d) If pid,, + L, then set (x, result) := (skq,, OK), else set 
(x, result) := (L, NOK). 
(e) Provide (pid, , 7, result) to Fape- 
(2) Upon receiving leakage (detecting ds, pid.,,) from fpc and being asked to 


provide z, ... 


(a) Set (pk, sky) = Áieys (pido 
(b) Provide x = skq to Fape- 


VerifyGuilt (for honest party): Upon receiving leakage (verifying guilt, pidq; 1) from 
Tape and being asked to provide result ... 


(1) Set (pku -) := Jieys pido). 
(2) If gf = pk,, then provide result := OK, else result := NOK to 75. 


^ This assignment exist. (detecting ds, pid,,) is only leaked, if the user truly committed double-spending. In 
this case Step 5 in Fig. 8.27 and Step 4 in Fig. 8.30 have been called previously. In all other cases the honest 


user and therefore Sppe knows sky, anyway. 


Figure 8.31: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator 5757 5** (cont.) 


BlacklistWallet (for honest operator): Upon receiving leakage 
(blacklisting wallet, A, x) from Fap¿ and being asked to provide ¢, provide 
p := PRF(A, x) to Fane. 


BlacklistWallet (for corrupted operator) (1) Upon receiving output 
(establishing-session, ssid, pido, blacklist_wallet) from Finsg for DR, ... 
(a) Set (pk pp, skpg) = Freys(Pid pg); if Áieys (Pid pp) is undefined, let 5,5; 

abort. 
(b) Call 75,4 with input (accept, ssid). 
(2) Upon receiving output (sent, cy) from Fmsg for DR, ... 
(a) Parse (27,4) := cy. 
(b) Assign (Ag, ..., Ap. ,, A", pkqy) = ENC1.Dec(skpp, Jj). 


(c) If decryption fails, call Fnsg with input (send, ssid, Ø) in the name of DR 
for the message from DR to O and halt. 


EA Ses A 4, A" lor A” # olds“ 
(d) If Aj AE pk gh ld 
(i) Set (pid, A) := (L, L). 
Else: 


(i) Set A := A" + Yj) DLOG(A/) - Bi. 
(ii) Set pid, == eras if For hap -) is undefined, set 
(pid, A) = (UL). 
(e) Call pc with input (blacklist wallet, cj). 
(3) Upon receiving leakage blacklisting wallet from fpc and being asked to 
provide (pid, A), provide (pid, ,, A) to Faye.’ 
(4) Upon receiving leakage (blacklisting wallet, A, x) from fpc and being 
asked to provide q, provide y = PRF(A, x) to ac. 
(5) Upon receving output (blacklisted wallet, blg,) from fpc for O, call Finsg 
with input (send, ssid, bla.) in the name of DR for the message from DR to O. 


(6) Upon receiving output (closed, ssid) from Finsg for DR, let fpc delivers its 
output to DR. 


This might hold, if œ is a simulated blacklisting tag for an honest user (cp. Step 1b in Fig. 8.23 or Step 4b in 
Fig. 8.24). 


?oON.b: 5; asks for alternative pid, À, if and only if @, has not been recorded internally. Le., for a simulated, 


but legitemately issued «yj, which encrypts a "useless" 1-vector, Siete is not compelled to provide (pid, ,, A). 


Figure 8.32: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Simulator S75 5** (cont.) 


RecalculateBalance (only for honest operator”): Upon receiving leakage 


(recalculating balance, blg, (fake) from Fy. and being asked to provide pleviate |. 
® p 8 p p 


(1) wfake ‚— {ere < ENC2. Dec(sko dnd , Orc) | Ore € a 

(2) wfake valid , = {(s.@, p. pk. Orc) € the | SIG. Vfy(pko, Ores (S, Q, gh) = 1} 
(3) E= (5) | 3e = G9 ps) € PRA y € big} 

(4) Provide pleviate .— by pee P 10 Fapc- 


^ This a local algorithm and hence there is nothing to simulate for a corrupted operator 


Figure 8.33: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 


Note, the modifications of hybrid Hj***5** are identical to hybrid gm 


Hybrid H25*75** (Simulate PoS' certificate) In hybrid H35*' 5** the task CertifyPOS is mod- 
ified. For an honest operator or an honest PoS the code of 113%" is replaced by the code of 
a dummy party. The simulator $59" 5** behaves in this case as the final simulator 7567 5*€ 
would. More precisely, if both parties are honest, protocol 77256" 5* is modified such that the 
simulator .S35€75€€ receives the message (certifying pos, pidp, ap) and creates the certificate 
Cert. If the PoS is corrupted, but the operator honest, the certificate cert? is also created by 
simulator .S25*' 5*6, If the PoS is honest, but the operator corrupted, simulator 259" 5** receives 
certo as part of the message from the operator. In either case, simulator $35" 5*^ learns cert 
and internally records it in Theva Whenever the honest operator or honest PoSes running 
7135**53** would send certp (or of") as part of their messages in the scope of IssueWallet or 


Deposit, they omit cert. Instead, the simulator S3°°"°°° 


injects certo into the messages. 


Note, except for the additional case that the PoS is honest and the operator corrupted, the 
modifications of hybrid H25*'5*** are identical to hybrid HE is 


Hybrid H25*"5** (Extract serial number) H1**"5** modifies the tasks of IssueWallet and 

Deposit in case of a corrupted operator/PoS. The code of 7715€" 5** for the user is modified such 

that it does not send s’ but randomly picks s and sends it to S156 5€€, Then SISersec extracts 
4) 


s" «— C4.Extract(crs cl), calculates s’ := s-(s’”)~1 and inserts s’ into the message from the 


user to the operator or PoS respectively. 


Hybrid H25*r5** (Simulate ZK-proofs) This hybrid modifies 725" 5** such that the honest 
users do not send any proofs. Instead, the simulator .$25€^5** appends simulated proofs to the 


messages from the user to the operator or PoSes without knowing the witness. 
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Simulator 575: *** (cont.) 


ProveParticipation (for honest user and honest violation enforcer): (nothing to do, note 
that Zap. only leaks, if user or violation enforcer is corrupted) 


ProveParticipation (for honest user and corrupted violation enforcer): (1) Upon 
receiving output (establishing-session, ssid, pid yp, prove_participation) 
from fs for U with pid, call Finsg with input (accept, ssid) in the name of 
U. 

(2) Upon receiving output (sent, ssid, pid,, pp) from ae for U, call Fape with 
input (prove participation, pid, pid, App) in the name of VE. 

(3) Upon receiving leakage (proving participation, oy) from fpc let Faye 
continue. 

(4) Upon receiving output (proved_participation, result) from Fape for VE, ... 


(a) If result = NOK, set Yop := L, else 
(i) Set (pkqp"):= freys (Pida) 
(ii) Set (pp. y= pp (pp) 
(ii) Set Cok, = Opp and parse (pk, Opp» dy. ) = Yop- 
(iv) dy. < C2.Equivoke(crs®).,, pkqp Cpk. p pk, )- 
(v) Redefine Ypp := (pKEP, Opp» dp.) and halo) a (Upp: PK). 
(b) Call mse with input (send, ssid, (@pp» Yop) in the name of 44. 


(5) Upon receiving output (closed, ssid) from TP for U, let fpc delivers its 
output to U. 


^ This exists as otherwise 7,,. would have returned result = NOK. 


Figure 8.34: The Simulator for User Security and Privacy (cont. from Fig. 8.19) 
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Hybrid H25*75*^ (Fake commitments for wallet ID and wallet components) Hy- 
brid FIS ets modifies Fire 06e such that honest users do not send the commitments c. id 
€g, and Cupd in the IssueWallet and Cipd in the Deposit task. Instead, S28*"S¢¢ injects suitable 


user-sec 


commitments to vectors of zeros. This equals the behavior of the final simulator S777 


Hybrid H7**'5** (Record Tags) H;75*'5** replaces the code protocol 775*'5** of the tasks 
IssueWallet, Deposit and Disburse such that the various tags are not exclusively created by the 
parties’ code but with support from $75€*5€* and then recorded by S¥S*rS°, More precisely, 


these are 


copy = (27,441) wgs = (p, 1,42) (8.34) 
Ore €— ENC2Enc(pk5 ^5, Vee) Opp = pk, (8.35) 


To this end, gry Set SEC and ,S75*"5** are changed in detail as follows. 


For the blacklisting tag «xj: In the scope of IssueWallet the code of honest user is modified 
such that it does not expect to receive the operator's share A" of the wallet ID. Instead, 
the wallet ID A is uniformly picked by S7%S° as fpc would do and A is provisionally 
provided to the user. Moreover, the honest user does not sent ijj, but S759 3*€ sets 
A’ := A: AT, creates the hidden part y; the same way as an honest user would do and 


sends it to the operator. Also, 75€ 5** records fo, (A) = «y; as Fape would do. 


For the double-spending tag wgs: The code for honest users is modified such that it explicitly 
leaks s, 9 to SY°°T5°, Also, they do not expect to receive the DS challenge u, nor reply 
with a DS response t. Instead, 757 3** intercepts u, when it is sent by the operator/PoS 
and manages a set a for each y in the following way. If OA is still empty, S¥sersee 
picks a random DS mask wy, calculates t = uz - sky, + uy, adds wg, :— (p,t, uz) to o. 
and replies with t to the operator/PoS.' If (o in not empty, 575*"5** picks an arbitrary 
(e,1’,u3) € o calculates t := t’ + skqy(uz — u5), and then proceeds the same way (cp. 
Step 1d in Fig. 8.26, Step 5c in Fig. 8.26, Step 1d in Fig. 8.29, and Step 4c in Fig. 8.30). 


For the recalculation tag «x: In the scope of Deposit/Disburse the code ¥S*™S°¢ of the honest 
PoS/operator is modified such that they ask S¥S*S°¢ for the final œe which is then output 
by PoS/operator. To this end they provisionally leak the honestly created cr; to SYS 5ec 
which replies with c, := @t.. Also, the honest PoS additionally leaks p in the scope of 


Deposit, if the operator is corrupted. 


? Note, that S¥S*™S° knows skq as the user is honest. 
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For the prove-participation tag @pp: The code of the honest users is modified such that they 
ask S759 5** for the final o, which is then output by the users. The honest user does not 
1 user-sec 1 1 

send Cpk,,, anymore nor expects to receive Opp- Instead, S} creates Cok dy. itself 


and injects 
user-sec 
$57 


Cok, into the message from the user to the PoS. When the PoS replies with opp, 
compiles (@pp, Ypp) = (pkey? (pk, Opp; dpk 2^: internally records Top ap) = 
(Jp. Pkq,) and provides wpp to the user. Moreover, when the honest user sends (pp, Ypp) 


in the scope of ProveParticipation, the honest user only sends c, and 75€" *** injects 
Yop using fp. 


In summary, these modifications leak (s, 9) (for w4,-tags) and—in case of a corrupted operator 
in Deposit—also p (for @,.-tags). This equals the behavior of the final fpc (cp. Fig. 4.11, Step 10 
and Fig. 4.12, Step 7). 

On top, 7:25€75*€ provisionally leaks cof, which is still honestly created by 7:759 5** and simply 


mirrored back by 


user-sec 
S7 


ST SES as @,.. This over-leakage is reverted in hybrid Hj7^'***. Also, 


exploits the user's identity to create @pp honestly, which the final simulator cannot 
do. This is repaired in hybrid H12€" cc. 


Hybrid H?5**5** (Decoupling the PRF) This hybrid introduces a new incorruptible entity 


Fo 


subroutine input/output tapes.” Fy. 
manages a partial map fg, mapping pairs of wallet IDs A and counters x to fraud-detection IDs. 
Whenever an as yet undefined value f(A, x) is required, Fang defines fg(A, x) = PRF(A, x). 


If an honest user or the simulator requests a fraud-detection ID ọ for (A, x), 


$50, x). 


-rand into the experiment that is only accessible by honest users and the simulator through 


rand Provides the following functionality: Internally, 7 grand 


Fp rand returns 


Hybrid Hj5*"5** (Create lookup table for double spending) When .S5**"5** compiles the 
set a within the scope of Deposit or Disburse (cp. hybrid H7**'5*^) and there exist matching 
double-spending tags wgs: c. € P then set f; (pida, 7) := OK with x := sk, to record this 


incident of double-spending as Size" would do. 


Hybrid Hj" 5*** (Utilize lookup tables for VerifyGuilt) In case the calling party is hon- 


op-sec 


est, this hybrid is the same as hybrid H; ^ . Otherwise this hybrid does not change anything. 


Hybrid Hi ¿"e (Utilize lookup tables for BlacklistWallet, forego decryption of black- 
listing tags) The dispute resolver DR becomes a dummy party and simply sends it input 


" Note, that S35e=Sec because it simulates Fn 
12 


sg internally and thus knows the identity of the user. 
Le., communication is confidential, reliable and trustworthy. One might think of this entity as a preliminary 
version of the eventual ideal functionality. 
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(blacklist wallet, pid, /) to the simulator S114" 5** in order to signal its consent to blacklist 
the user. The simulator 5114" *** utilizes fo, from hybrid H7*** *** and runs the joint code 
as the ideal functionality Zap. and Sigo. would do eventually. Especially, .511*" 5** checks 
fa, (cx) to decide whether œ is a genuine or a fake tag. If A := fa, (cx) is defined and hence 
denotes a genuine tag, simulator .S71*' *** does not decrypt «yj, but used the recorded wallet ID 
A and F grand to create the blacklist blg,. If A := fa, (cj) is undefined and hence denotes a fake 
tag, simulator S10 5°" decrypts cj as the real dispute resolver would do. If the decrypted user 
ID pid,, denotes a corrupted user, simulator SY} 5* creates a blacklist b/g, using the real code. 
but directly uses the PRF to obtain a list of 


fraud-detection IDs bla, := (9; o. .... 91, und! for the decrypted wallet ID A. If the decrypted 


Especially simulator SY} *** does not call Fy rand» 


user ID pid,, denotes an honest user, simulator STU 5** creates a blacklist blo, uses F rand: 


Hybrid H¡¿9"*e (Utilize lookup tables for RecalculateBalance, forego decryption of 
recalculation tags) When the task RecalculateBalance is invoked, S53 °° partitions the 
set of recalculation tags Q,. into two set oo. and (fake the same way as Fapc would do. 


eo are not decrypted, but SY5*"S¢° uses the serial number and 


€ fake 


Recalculation tags (y. € 
genuine , 


price of the original transaction to create a set E = {(s, p)}. Recalculation tags c € 
are still decrypted, their signature is checked for validity and Zfake := {(s, p) is compiled from 
the decrypted values. Then the balance is calculated as bPill := Èc, pyezgenuine p : Dí p)eztke p. 

This behavior equals the joint behavior of fpc and the final simulator Se (cp. Figs. 4.16 


and 8.33). 
The modifications of hybrid H15**5** are identical to those of hybrid in wd 


Hybrid H13°"°°° (Utilize lookup tables for ProveParticipation, forego unveil of prove- 
participation tags) This hybrid utilizes top to link legitimately issued prove-participation 
tags to their origin. The code of the honest users is modified such that they do not send 
(Opp: Ypp) but only «yy. Also, the users do not internally test, if «yj, is one of their own prove- 
participation tags, but simply forward them as a dummy party would do. If the result is positive, 
S13 *** looks up the corresponding ppp in [m and simulates the message (pp, Ypp). Note, Ypp 
are not yet equivocated (as the final simulator would do), but SY3*S° sends the original i, 
that have been recorded in hybrid H7*** cc, 


Note that hybrid H12*' ** is a simplified variant of hybrid E sec. In hybrid H}er-sec, only 
honest users interacting with a corrupted violation enforcer need to be considered. If the 
user was corrupted, the violation enforcer would have to be corrupted, too, as required by 
Theorem 8.28. 


Hybrid H12*"5** (Fake blacklisting tags for honest users) The code 4° *** for honest 
users in the scope of IssueWallet is modified such that they do not send «yj. Instead, SY4°"°°° 
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returns cy, := (A", Ypi) with Jg; = ENC1.Enc(pk pp» (1,...,1)), when O asks for a «yj (cp. hy- 
brid Hy), 


Hybrid Hi“ (Use truly random fraud-detection IDs) Hybrid H12*"5** replaces the 
PRF inside f, 


-ran 
q independently and uniformly draws a fresh random fraud-detection ID p and 


a by truly random values. Whenever an as yet undefined value fg(A, x) is 
required, Tuan 


sets fa(À, x) := q. 


Hybrid Hi¿“"*““ (Fake double-spending tags for honest users) The code 776° 5** for 
honest users in the scope of Deposit and Disburse is modified such that they do not send a 
real DS response t. When the operator asks for double-spending tag (cp. hybrid H2**'5*€), the 
simulator .S75€' 3€ proceeds as follows. If no (o, t", us) € Qr has been recorded previously, 


Suser-sec user-sec 
16 


picks t e Zp randomly. This equals the behavior of the final simulator 757 


op-sec 


Note, the modifications of this hybrid are identical to hybrid H,; 


Hybrid Hyyers°* (Fake recalculation tags for honest users) The code 7}*"S°¢ for honest 
operator/PoS in the scope of Deposit and Disburse abandons the over-leakage of w;, that has 
provisionally been introduced by hybrid H7**"***, When they ask for wre the simulator does 
not simply reflect wre := (fc, but instead creates w,. on its own. The simulator does so in two 
different ways, depending on the corruption status of the operator. 

If the operator is corrupted,'* the simulator creates Y. = (S, Q, p. pkp» Ore) With o4, <— 
SIG.Sign(skp, (s, 9, g?)) faithfully and provides a true encryption o, + E NC2.Enc(pko ^^^, Yro). 
We stress that 517?" 5*^ knows all relevant information s, 9, pid, and p due to the leakage 
introduced by hybrid Hy*er sec, 

If the operator is honest, 575€" 5€ provides an encryption cy, = ENC2Enc(pk5 ^5, Wee) for 


an arbitrary V4, from the correct space. 


op-sec 


Note, the modifications of this hybrid are identical to hybrid uhr: 


Hybrid Hj$*" *** (Fake prove-participation tags for honest users) The hybrid H13°s°c 
modifies Deposit and ProveParticipation. 
In Deposit the simulator S}3" *** does not use the user's identity to create (cy, Ypp). Instead, 


Sig °° simulates the commitment as (ok, d, ) — C2.CommitSim(crsQ),), SUSTSEC sets 


= = pp d F m 
Opp = Cok, and Yop = (pkp > Opp» doky) returns Wp, and defines fop(pp) = (Yop, gı). 
Moreover, the code for ProveParticipation in case of an honest user and a corrupted violation 


enforcer is adapted (cp. hybrid H}$°™5°°). After ST2*" 5*6 has looked up the corresponding 


7  N.b. for operator security the operator is always honest, i.e. this case never holds. However, we explicitly consider 


this case here, as this allows us to reuse this hybrid as hybrid H17**5** to prove user security. 
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Yop 81) = op pp). but before sending Ypp to Z*P"* playing the corrupted VE, ST; 5e 
parses COI Gop: dor) ‘= Jp). equivocates the decommitment d Pky © C2. Equivoke(crs(2) , 
Pkap Cpk, doky) redefines Ypp = (KP, Opp: doky) and then sends Yov. 

op-sec 


Npsc 


As before, the proof of Theorem 8.28 is shown by the pairwise indistinguishability of 


Again, this equals the behavior of the final simulator S 


subsequent hybrids. Most ofthe proofs have already been shown in a similar vein in Section 8.3. 
In those cases, the proofs are either only sketched or the reader is referred to the corresponding 


proof in the previous section. 


Lemma 8.29 (Indistinguishability between Hj5*'5€* to Hj5€r-5ec, Hgser-sec to HISS ses, 
Hye SSS to H12*75*5, as well as H15** 5** to H12*^ 5*5, resp.) Under the assumptions of The- 

user-sec € | € jjuser-sec pyuser-sec £ ,., € jjuser-sec jjuser-sec € 
orem 8.28, Hy =.=H , He =- = Hio ‚Hi = 


user-sec € .., € jjuser-sec 
Hye = SH , resp. holds. 


Ile 


Hg see. and 


Pnoor The indistinguishability H¿$ersec = = puser- sec is proven similar to the proof of Lemma 8.4. 
However, with respect to the CRS of the NIZK scheme the composable zero-knowledge property 
of Definition 6.9 has to be used. 

The Bon within the sequence of hybrids Hj**r5cc = Hysersee = Hysersec and 
HEEE £ = Hysersec = = Huser- cS = Huser- sec are only syntactical. Therefore, the same argument 
as for Lemma 8.5 applies. Note, the tentative functionality 7, rang Which is inserted by the hop 
from H75*'5*€ to H35€^5** is inaccessible by Z/"**"5** and still uses the real PRF to generate 
fraud-detection IDs. 

The hop from H25*' *** to H15*'5** does not change anything from the perspective of Z "5€ 5cc 
as C4 is perfectly F,„-extractable (cp. Definition 6.11, Item (4)). 

The hop from Hj**'5** to H15*75*€ is identical to the hop from hybrid HS Sec to HT see See 
proof of Lemma 8.18. 

The chain of indistinguishable hybrids Hee £ Hygersee £ Hyger see = Hi" 5** corre- 
sponds to H3 ^ = £ "a — a = oy... See Lemmas 8.20, 8.23 and 8.24 for the proofs. 
Note that for the hop from Hi" to H15*'5** only the case of honest users needs to be 
considered in Lemma 8.23. If the user was corrupted, the violation enforcer would have to be 
corrupted, too, due to the restrictions imposed by Theorem 8.28. 


= c = c T [e] kis -| c 

The sequence H12€r5ec = HEST Sec E Hyer see = jer ec is identical to HT MESS £P see 5 

pop=sec € ¡yop-sec 
26 = 127 


and proven by Lemmas 8.25 to 8.27. 


Lemma 8.30 astenga hability between H7*5**5** and H25**5**) Under the assump- 


tions of Theorem 8.28, Hyser-sec = = puser- sec holds. 
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Pnoor This hop replaces the real proofs by simulated proofs. To show indistinguishability 
despite this change, we actually have to consider a sequence of sub-hybrids—one for each of the 
different ZK proof systems P1, P2 and P3. In the first sub-hybrid all proofs for P1 are replaced 
by simulated proofs, in the second sub-hybrid all proofs for P2 are replaced and finally all 
proofs for P3. Assume there exists Z''5*" *** that notices a difference between H75*" 5** and the 
first sub-hybrid. Then we can construct an adversary 8 that has a non-negligible advantage 
Adva x(n). Internally, 8 runs Z"S*TS€¢ and plays the protocol and simulator for Z"5er'sec, 
All calls of the simulator to P1.Prove are forwarded by 8 to its own oracle in the external 
challenge game which is either P1.Prove or P1.ProveSim. 8 outputs whatever Z"5€"5*€ outputs. 
The second and third sub-hybrid follow the same line, but this time 8 internally needs to 
generate simulated proofs for the proof system that has already been replaced in the previous 
sub-hybrid. As 8 gets the simulation trapdoor as part of its input in the external challenge 


game, 8 can do so. = 


Lemma 8.31 (Indistinguishability between H25*'5*€ and H25**5€€) Under the assump- 


2 “ Cc = 
tions of Theorem 8.28, e holds. 


Pnoor In this hop the commitments G id» fix: Cupd and e pd are replaced with commitments to 
zero-messages for every honest user. Again, the hop from Hz5*'5** to Hgser-sec is further split 
into a sequence of sub-hybrids with each sub-hybrid replacing a single commitment in reverse 
order of appearance. Assume Z"°*™S¢¢ can distinguish between H25*" 3*6 and Hgser-sec with 
non-negligible advantage. This yields an efficient adversary B against the hiding property of 
C1. Please note that none of the commitments are ever opened, hence in each sub-hybrid only 


a single message is replaced. Internally, 8 runs Z"5er^sec 


and plays the role of all parties and 
the simulator for ZUSe""sec, Externally, 8 plays the hiding game. First, 8 guesses the index i of 
the sub-hybrid which lets Z"5er^5€c distinguish. For the first (i — 1) commitments, 8 commits to 
the true message. For the itt commitment, 8 sends the actual message and an all-zero message 
to the external challenger. 8 embeds the external challenge commitment (either to the actual 
message or the all-zero message) as the itt commitment. All remaining commitments are 


replaced by commitments to zeros. 8 outputs whatever Z/"5€"5€€ outputs. " 


Lemma 8.32 (Indistinguishability between Hj5*'5** and Hy?°" °°) Under the assump- 
tions of Theorem 8.28, Hi **c £ HFSS holds. 


Pnoor This hop is perfectly indistinguishable from the environment’s perspective as the 
modifications made by hybrid H17*'5** do not change the output. Note that the dispute resolver 
is always honest. At the bottom line, identicalness of the outputs follows from the correctness 


of ENC1. If the operator is honest, too, the argument from Lemma 8.19 applies. If the operator 
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is corrupted, the operator might send a blacklisting tag «y; which is not genuine. In this case, 
0 is still decrypted as the real dispute resolver would do. Note that F; rang still uses the PRF 
internally, hence the resulting blacklist is perfectly indistinguishable from the previous hop, no 


matter whether the user under consideration is corrupted or not. " 


Lemma 8.33 (Indistinguishability between H17*"5** and H12*^5**) Under the assump- 
tions of Theorem 8.28, Hier sec £ Hysersec holds. 


Pnoor In this hop the pseudo-random fraud-detection IDs for honest users are replaced by 
uniformly drawn random IDs. Again, we proceed by introducing a sequence of sub-hybrids. In 
each sub-hybrid the fraud-detection IDs for one particular wallet ID A are replaced. If ZUser-sec 
can distinguish between two of the sub-hybrids, this immediately yields an efficient adversary 
against the pseudo-random game as defined in Definition 6.17. Internally, 8 runs Z“$e""S€c and 
plays the protocol and simulator for Z"S°™S°. Externally, 8 interacts with an oracle that is 
either a true random function R(-) or a pseudo-random function PRF(A, -) for an unknown seed 
À. Whenever B playing F y-rana internally needs to draw a fraud-detection ID for the particular 
wallet A, 8 uses its external oracle. B outputs whatever Z"5€"5€€ outputs. Please note, this 
argument crucially uses the fact that Z"S°"S¢¢ is information-theoretically independent of A. 
The blacklisting tags V; have already been replaced by encryptions of 1-vectors in the previous 
hybrid H12*'5**. This enables the external challenger to pick any seed À. " 


Again, we conclude this section by gathering the results and repeating the initial theorem. 


Theorem 8.28 (User Security and Privacy) Under the assumptions of Iheorem 8.1 


T cns f wn 
Tpsc "UC Fape (8.32) 


holds under static corruption of 
(1) a subset of PoSes, operator and violation enforcer, or 
(2) all PoSes, operator and violation enforcer as well as a subset of users. 


Proor A direct consequence of Lemmas 8.29 to 8.33. = 
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In order to evaluate the practicality of P5C, we reconsider the performance figures from 
[Nag+17; Nag+20]. Please note, that in neither case the exact protocol as presented here is 
implemented. In [Nag+17] BBA+ lacks many of the functional improvements, especially the 
blacklisting mechanism. Therefore, no costly range proofs to escrow the secret wallet ID are 
necessary during IssueWallet. Moreover, BBA+ does not support user/PoS attributes. Hence, 
the message sizes and zero-knowledge proofs are smaller. In [Nag+20] a scheme which includes 
all functional features has been implemented and thus it is very close to the scheme presented 
in this thesis. Still, the belated fixes which have been introduced by this thesis are missing. 
However, the fixes have not changed the computationally costly zero-knowledge proofs and 
thus should only have little impact on the performance figures. 


In summary, the following implementation figures have to be taken with a pinch of salt. 


931 Hardware 


As to the hardware, the users, the PoSes and the remaining parties, mostly the operator 
but also the dispute resolver and violation enforcer have to be considered separately. For 
the latter group it is reasonable to assume that they may use typical PC hardware, or—if it 
was necessary—reasonably powerful workstation/server hardware. In [Nag+17; Nag+20] the 
runtime of the operator (also known as toll service provider in [Nag+20]) is measured on a 
standard laptop featuring an i7-6600U processor for simplicity. In contrast, users and PoSes 
are typically equipped with hardware which only offers lower computational powers, because 
it has to be mobile, is deployed in the field or embedded into another system. 

For BBA+ [Nag+17] the authors consider a pre-payment system or customer loyalty program. 
Hence users are assumed to be individuals who use their smartphones to manage their wallets. 
In [Nag+17] the user side has been implemented on a OnePlus 3 smartphone. It features a 
Snapdragon 820 Quad-Core processor (2 x 2.15 GHz & 2 x 1.6 GHz), 6 GB RAM and runs 
Android OS v7.1.1 (Nougat). 

For the feature-complete scheme in the ETC setting [Nag+20] the user side correspond to 
vehicles. The user side has been measured on an evaluation board that features an iMX6 
Dual-Core processor running at 800 MHz with 1 GB DDR3 RAM and 4 GB eMMC Flash. The 
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processor runs an embedded Linux, is ARM Cortex-Ag based (32-bit), and also exists in a 
more powerful Quad-Core variant. The same processor is used in real vehicles as part of the 
Savari MobiWAVE-1000 on-board unit [Savı7]. For the PoS hardware, which corresponds to 
toll gantries, we take the ECONOLITE Connected Vehicle Coprocessor Module as a reference 
system, which was specifically designed to enable third-party-developed or processor-intensive 


applications [ECO18] and measured on comparable hardware. 


9.2 Parameter Choice and Instantiation of 


Setup Assumptions 


As for the bilinear group setting, we use the Barreto-Naehrig curves Fp254BNb and Fp254n2BNb 
[BNo6; Kaw+16] and the optimal Ate pairing since this choice results in the shortest execution 
times [Moo+15]. This yields a security level of about 100 bit [BD17]. 

In [Nag+20] the scheme is evaluated for two sizes of attribute vectors: |aq,| = lap] = 1 and 
lag = |ap| = 4. With curves of 254-bit order, each vector component can encode up to 253 bits 
of arbitrary information. In practice, it should be possible to encode multiple attributes into 
one such component. 

The secure messaging functionality of Fnsg to securely exchange protocol messages has 
been realized by the IND-CCA-secure encryption scheme from [CKS08] in combination with 
AES-CBC and HMAC-SHA256. The remaining two setup assumptions Fors and Fpp have not 
been implemented as independent components, but hard-coded. This is reasonable for the 
CRS which becomes a fixed system parameter after it has been generated trustworthily and 
standardized once. Using a static list of keys for Fy, is viable for a testbed, but has obviously 
to be replaced by a key registration service in reality. Please note, that the latter has no impact 
on the runtime measurements which are considered here. The remaining building blocks have 


been instantiated as in Section 6.2. 


9.3 Tool Chain, Libraries and Optimizations 


The scheme is implemented C++17 using the RELIC toolkit v.o.4.1, an open source cryptography 
and arithmetic library written in C, with support for pairing-friendly elliptic curves [AG16]. 
We developed our own library for Groth-Sahai NIZK proofs [EG14; GS08] and employed 
the method in [CCs08] to realize the range proofs. In order to utilize the capabilities of our 
hardware, the user side algorithms were optimized for two CPU cores. We also optimized the 
computations performed by the operator/PoS, taking advantage of the four CPU cores and the 
batching techniques for Groth-Sahai verification by Herold et al. [Her+17]. 
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lag] = lap] = 1 lag] = lap] = 4 

Protocol tuser top/pos user Mop/pos fuser lop/pos "user “op/pos 

[ms] [ms] [byte] [byte] [ms] [ms] [byte] [byte] 
IssueWallet 27064 8490 87951 944 27183 8545 88107 1152 
Deposit 
- Offline 2749 2750 

(pre-/post-processing) 

- Online 348 475 8128 976 456 5256 8336 1088 
- Online 41 475 8128 976 40 526 8336 1088 


(cached certificate) 


Runtime t is averaged over 1000 executions. Transmitted data n is rounded up to full bytes. 


Table 9.1: Performance results of [Nag+20] 


9.4 Implementation Results 


In this thesis we only reconsider the most important results and concentrate on the main tasks 
which include the expensive NIZKs. Table 9.1 shows the results of our measurements for the 
feature-complete scheme in the ETC setting in terms of execution time and transmitted data. 

The performance of the task IssueWallet is dominated by the key escrow mechanism which 
requires to split the secret wallet ID into a B-ary representation and proof its correctness. This 
has a major impact on the zero-knowledge proof both in terms of runtime and size. This is 
also reflected by the fact that the number of attributes has only a slight effect. At first glance, a 
runtime of roughly 35 seconds appears impractical. However, the task is not time-critical and 
only needs to be executed once per wallet. 

Also, the task Deposit is dictated by the zero-knowledge proof. Without any further opti- 
mizations the task would require (2 749 + 348 =) 3 097 ms at the user side and 475 ms at the PoS 
side or 3 572ms in total. Clearly, this is too long for practical use. Fortunately, all parts of the ex- 
pensive NIZK proof which are independent of the challenge value u, can be precomputed. This 
includes all but one equation of the zero-knowledge language. Also assembling the updated 
wallet after the last message has been exchanged can be moved to a post-processing phase. 
This way the computation time at the user side can be reduced to 348 ms between the first and 
the last message. When caching valid PoS certificates, the runtime can be further reduced to 
approximately 40 ms. The computation time at the PoS is dominated by the verification of the 
NIZK and thus cannot be outsourced. In summary, all computations in the online phase of 


Deposit can be performed in about 515 ms. 
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luser lop/pos Nuser Nop /pos 


Protocol 

[ms] [ms] [byte] [byte] 
IssueWallet 129 89 672 352 
Deposit 
- Offline (pre-/post-processing) 285 
- Online 76 436 4576 464 
Disburse 


- Offline (pre-/post-processing) 268 
- Online 76 430 4544 464 


Disburse (with range proofs) 


— Offline (pre-/post-processing) 271 
- Online 623 853 13920 448 


Table 9.2: Performance results of [Nag+17] 


Table 9.2 shows the performance results of BBA+ from [Her+17]. First note, that BBA+ 
[Nag+17] has no support for user attribute vectors and also does not use PoS certificates. 
This means the results needs to be contrasted with the results for one attribute and cached 
certificates in Table 9.1. 

The task IssueWallet is faster by magnitudes, because BBA+ has no blacklisting mechanism 
and thus does not need to perform a costly range proof to escrow the wallet ID. This is reflected 
in runtime and message size. The combined runtime for the user and operator is 218 ms vs. 
35 s and the combined message size is 1 kB vs. 89 kB. 

The performance of the online phase of Disburse for BBA+ [Her+17] is approximately in the 
same scale as for the ETC system in [Nag+20]. The computation time is 76 ms vs. 41 ms at the 
user side and 436 ms vs. 475 ms at the PoS side. The differences at the user is due to the use of 
different hardware, i.e. a smartphone vs. an OBU evaluation board. The amount of transfer 
data in [Her+17] is approximately half of the amount in [Nag+20]. Remember, that [Her+17] 
is missing some features. Hence, no prove-participation tag is sent and the NIZK is smaller, 
because fraud-detection IDs are not images of a PRF but randomly drawn and the NIZK lacks 
the attribute vectors of the user and the previous PoS. 

Also, Herold et al. show performance results for a different variant of the task Disburse. In 
our running prime example, Disburse simply unveils the current balance of the wallet. This also 
matches the scenario in [Nag+20]. In this case the performance of Disburse is approximately 
the same as for Deposit. Alternatively, Disburse may use range proofs to show that the wallet 


contains sufficient funds. Typically, pre-payment scenarios benefit from the higher privacy 
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and are discussed in Section 2.3.2. In this case, the runtime increases by a factor of eight at the 
user side and nearly doubles at the PoS side. Also, the amount of data which is sent by the user 


increases by a factor of three. 


9.4.1 Storage Requirements 


The storage requirements are of no concern with respect to today’s hardware. The wallet itself 
consumes 1kB of memory and is fixed in size. During Deposit, the user and the PoS collect 
data in order to, e.g., prevent double-spending or to prove participation in a protocol run. In 
Deposit, the user has to store 137 bytes of transaction information and (optionally) 268 bytes to 
cache the PoS certificate for later re-use. Assuming that users perform 10000 transactions in 
one billing period, they have to store 1.37 MB of transaction information and, even if all visited 
PoSes were different, 2.68 MB of cached certificates. 

A PoS has to store 246 bytes of transaction information after each run of Deposit for the 
double-spending tags, prove-participation tags and recalculation tags. All this information 
is eventually aggregated at the operator’s database. Even for large scale deployments with 
hundreds of millions of transactions per month, the resulting database would only consume a 


few gigabytes. 


9.4.2 Computing DLOGs 


To blacklist a user, the dispute resolver has to compute a number of discrete logarithms to 
recover the wallet ID A. With our choice of parameters, A is split into 32-bit values, thus 
resulting in the computation of eight 32-bit DLOGs. While DLOGs of this size can be brute- 
forced naively, the technique of Bernstein et al. [BL12] can be used to speed up this process. 
Using their algorithm, computing a discrete logarithm in an interval of order 2?? takes around 
1.5 seconds on a single core of a standard desktop using a 55 kB table of precomputed elements. 
These precomputations need to be done only once by the dispute resolver when setting up the 
system and take one hour on a desktop computer. Thus, the required DLOGs can be computed 


in reasonable time by the dispute resolver. 
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10 Summary, Open Problems and 
Future Work 


The final chapter of this thesis serves two purposes. First some improvements of the definition 
of Faye and the scheme psc are discussed. Section 10.1 deals with smaller improvements. These 
improvements are rather straight-forward and have been discovered during the writing of this 
thesis, but have not found their way into the final version. Section 10.2 discusses what has to 
be changed to enable simulation-based security not only under restricted sets but also under 
arbitrary corruption of the parties. This change comes at the cost of less efficiency. Finally, 
Section 10.3 concludes the thesis and give some pointers to future work beyond the rather 


simple improvements which already has been discussed. 


1031 Minor Improvements 


The following three minor improvements are not expected to cause any problems or provide 
any new insights. The first one only affects a seemingly inconsequential design decision that 
has been (badly) determined in a very early stage and pervades the whole system. Hence, it 
has turned out not to be fixable without much labor in exchange for very little benefit. The 
other two improvements have been unveiled when the synchronization of the transaction tags 


has been formalized explicitly. 


10.1.1 Wallet Handles 


The first improvement removes the serial number s from all input/output in all tasks. Instead, a 
newly introduced wallet handle—which must not be confused with the (secret) wallet ID A—is 
used where needed. The serial number is given as output to the user only to enable several 
wallets per user and to provide the user with an option to denote which wallet should be 
used in a particular task. But the serial number is actually too much. It does not only denote 
a wallet but a whole wallet state and thus also empowers formally honest users to commit 
double-spending. This leads to the awkward distinction between honest and well-behaving 


users on the one hand side and honest but misbehaving users on the other hand side. 
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Although outputting the (secret) wallet ID A to the user seems to be what is wanted, this does 
not work out, because it would allow the environment to evaluate the PRF and check for real 
fraud-detection IDs vs. ideal fraud-detection IDs. At the bottom line, this is the same problem 
as in the formalization of symmetric encryption in UC. There, the (secret) encryption key must 
not be output to the environment, as the environment could distinguish encrypted messages 
from random simulations, but still an option to select which key shall be used is required. The 
solution is to introduce wallet handles which are truly random numbers and map one-to-one 
and onto the underlying wallet ID, but are information-theoretically independent of the fraud- 
detection IDs. More precisely, at the end of IssueWallet the user (and only the user, not the 
operator) obtains a wallet handle that is internally drawn by 9%). and mapped to the wallet 
ID. The user re-inputs the wallet handle into Deposit and Disburse. Internally, Fipe looks up 
the latest state of the corresponding wallet. This way honest users are also unable to commit 
double-spending. Still double-spending is possible, but the user must be formally corrupted 
first. For the latter, Zap. asks the adversary to provide the serial number of an alternative wallet 
state, if the user is corrupted. Hence, the distinction between well-behaving and misbehaving 
(honest) users can be dropped. 

The introduction of wallet handles allows to get rid of some inelegant leakage. In IssueWallet 
and Deposit the fpc explicitly leaks the serial number s to the adversary. Although this is not 
a serious problem, because s is a random number, the only reason for the leakage is to enable 
the simulation of a Blum cointoss which is consistent to the later output. If the serial number 
is not output, the Blum cointoss can be simulated blindly. This also applies to some other tasks. 

All in all, this modification would lead to a cleaner, more concise and more “semantical” 
interface. However, the change is not only a cosmetic one. The observation of the previous 
paragraph with respect to the Blum cointoss is also a key element for the extension to full- 


fledged security under arbitrary corruption (cp. Section 10.2). 


10.1.2 Recalculation Tags 


The next improvement affects the recalculation tags œc. As stated in Sections 4.4.3 and 7.4.3 
only very little guarantees are provided. The operator must rely on the PoSes that they 
provide correct and complete sets of recalculation tags. Although, the hidden recalculation 
tag Yre = (5,9, p. pkp» Cre) is signed by the PoS this does not ensure that the signed price p is 
actually the same price as used in the transaction. Also, corrupted PoSes can create additional 
recalculation tags or drop them. 

As an intermediate step, the hidden recalculation tag V4. could be sent to the user. This way, 
the PoS is deterred from dropping a recalculation tag, because the user owns a copy which is 


validly signed by the PoS. The corrupted PoS can still put a different price into its copy of the 
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recalculation tag, but the user can check this and immediately file a claim out-of-band. This 
intermediate step would likely increase the security level in a “practical” sense, but cannot be 
formally captured by the model and a corrupted PoS can still inject additional recalculation 
tags. 

A more comprehensive solution would also make the user sign the recalculation tag. This 
way, the PoS cannot unilaterally alter the price later and also not create fake tags. However, 
this solution comes with two obstacles. 

A straightforward signature o7; by the user contradicts the user's privacy in Deposit as 
the PoS somehow needs to check its validity. Instead, the user is equipped with a signing 
key pair (pkp skqq) whose public part pku needs to be certified, i.e. signed by the operator, 
similar to what is done in CertifyPOS for PoSes. This could either be part of IssueWallet or an 
independent task. Under the assumption that the signing scheme has the non-standard, but 
quite natural security property that a pure signature o77 does not unveil anything about the 
public key pku under which it is valid, the following approach is possible. The user signs the 
recalculation tag and sends the signature o7; together with a NIZK proof z'* that the signature 
is valid under an (anonymous) user key which again is validly signed by the operator. Then the 
hidden recalculation tag is extended to V, = (s, 9, p, pkp.» mre, 0p, 073) with Op = oy, denoting 
the PoS signature as before. Please note, that this is very closely related to the concepts of 
group or ring signatures. If the signature scheme unveils the public key for which it is valid, 
then the signature 075 can additionally be encapsulated in a commitment. We stress that it 
does not suffice, if the participating PoS is convinced that the user has signed the recalculation 
tag, but the operator who collects all recalculation tags later, needs to be convinced, too. 

Unfortunately, this comprehensive solution does not only increase the computational com- 
plexity of Deposit but also requires an additional round of communication. The user can only 
create o7; after the price p has been learned. At the current state, Deposit sends p as part of 
the last (i.e. third) message from the PoS to the user (cp. Fig. 7.20). This message also sends 
the updatable commitment cupa and the associated signature Cupa- These components must 
remain in the last message, as otherwise a malicious user could run away with a new wallet 
before Deposit is completed. Hence, it is not admissible to only add one additional message 
in which the user sends (#'°, 073) at the end, but instead the currently third message becomes 
the fifth message, the price p is pushed forward to a newly added third message and the user 
sends (1175, 0,7) in the newly added forth message. 

Finally, the task RecalculateBalance needs to be extended into a two-party task involving 
the user. The user and the operator both input their set of recalculation tags and both sets are 
united. This way, neither side can drop a recalculation tag. For the case that the user does not 
agree to participate, RecalculateBalance can still be run by the operator alone using the empty 


set Ø for the user's input. 
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Skipping ahead, the merger of the improved recalculation tag with the improved prove- 
participation tag (cp. next section) into a joint receipt tag seems appealing, because both share 
overlapping information and thereby modeling a true digital counterpart of a physical invoice. 


However, this is only syntactical embellishment. 


10.1.3 Prove-Participation Tags 


The prove-participation tags exhibit a practical problem that is very similar to the afore 
discussed recalculation tags. The PoS which has triggered the violation enforcer to physically 
identify a user is the same PoS which also provides a set of prove-participation tag Qpp to the 
violation enforcer. This allows a PoS to intentionally embezzle the relevant prove-participation 
tags which are connected to the incident and thereby disable the user to refute the accusation (cp. 
Sections 4.4.4 and 7.4.4). Note, that the hidden prove-participation tag Yop = (pkyp ‚Opp» dy.) 
already contains a signature on the prove-participation tag @pp = pk, by the PoS. At least, 
this allows users to prove that they have participated in some transaction with the accusing 
PoS, but it does not prove that this has been the specific transaction under investigation. 

In a former approach the serial number s has been part of Ypp, but s is as random as the 
commitment value Cpk, does not establish a connection to the transaction and thus does not 
solve the problem. To solve the problem once and for all, the violation enforcer needs to be 
able to autonomously relate the physical identification (e.g. a photo) to some information about 
the transaction without relying on the PoS to assist with this mapping honestly. 

In practice, the solution is quite easy. An improved prove-participation tag would encode the 
actual whereabouts of the transaction including a location, which is already given by the PoS’ 
identity and position, and a timestamp. This timestamp would also be included in the photo and 
thus could be matched. A timestamp is an example of a “publicly verifiable information" (cp. 
Section 2.4). Each party has its own time source which it trusts. Depending on the scenario and 
the frequency in which a user participates in a transaction with the same PoS the timestamps 
only need to match approximately. A practical solution would be as follows: The user commits 
to its public key pk, as before and sends Cok, tO the PoS together with its own timestamp 
tsqy- If tsq is sufficiently accurate, i.e. within a specified distance from tsp, the PoS signs the 
tuple (pi, tsq) and sends oy, back to the user. If anything fails, the PoS triggers the violation 
enforcer (as before) which takes a photo and equips it with its own timestamp tsyr. Later, 
the physically identified user is challenged on (pid,, tsyg). If the user can present a prove- 
participation tag which is signed by the correct PoS, has a timestamp ts4, close to tsyg and can 
be unveiled to the user's own public key pk, then the user is discharged. Note, that this way 
the violation enforcer does not need any input from the PoS. 

Unfortunately, this apparent solution cannot easily be modeled in the UC framework, al- 


though the basic idea of Fis seems easy. The hybrid i is augmented by an ideal 
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timestamping functionality Fis. Fts is a n-ary functionality (for arbitrary n) that upon request 
outputs the same timestamp to all n parties. Within the scope of the (abstract) model a simple 
integer that is increased for each request suffices as a timestamp. As each of the n parties per 
request gets the identical timestamp, we do not need to deal with (real-world) inaccuracies 
neither. The main problem is the formalization of 7, and is more involved than it may seem. 
UC is inherently asynchronous and message driven, i.e. to be accurate 7, cannot output to 
n parties at once, but looses its activation after each output to a single party. Moreover, the 
adversary is not obliged to re-schedule 7, right away, but may let other parties run first. This 
also accounts to the problem that 7,, cannot know if the n first parties which request f, for a 
timestamp actually belong to the same transaction and thus should receive the same timestamp 
or if these n parties belong to different transactions and therefore some of them should receive 
a different timestamp. These problems can be overcome ([Kat+13]), but the formalization is 
surprisingly intricate. 

As already said in the previous section, the improved prove-participation tags and the 
improved recalculation tags suggest themselves to be combined into on sort of tag, as they 


share a lot of identical information after the extension. 


10.2 Towards Full-Fledged Corruption 


In Chapter 8 mpsc is proven to be secure UC-realization of fpc for restricted sets of corruption. 
We observe, that full-fledged indistinguishability is possible, if an extractable commitment 
scheme is used. 

Let's temporarily ignore the commitment scheme C4 for the serial number s in IssueWallet 
and the Blum cointoss as well as the the commitment scheme C2 used by the prove-participation 
tags to hide the user's public key. We fist concentrate on the commitment scheme C1, which is 
used to create the fixed and updatable commitment cg, Cupd of a wallet, and the NIZK proofs 
P1, P2 and P3 in IssueWallet, Deposit and Disburse, resp. 

A close look at the simulators for operator and user security, especially how they setup the 
CRS (cp. Figs. 8.2 and 8.19), shows that 


(1) The NIZK proof schemes P1, P2 and P3 are used in extraction mode (for operator security) 


and in simulation mode (for user security). 
(2) The commitment scheme C1 is setup honestly (in both cases). 


(3) All (secret) witnesses which are extracted from the NIZK proofs z (in case of operator 


security) are also contained in the commitments cg, c 


upd TESP. 


(4) A user only creates the commitments cg, and Cypa» but never unveils them. 


pd? 
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With respect to the second item, we note that C1 allows to be setup for equivocation, but 
this property is not needed in the proof. With respect to the last item, we stress that cg, and 
Cupa are neither unveiled in IssueWallet nor in Deposit, but only homomorphically modified. 
Although the balance b is unveiled in Deposit, the commitment Cy q itself is not opened but 
only unveiled indirectly by means of a NIZK proof that shows that the user knows a consistent 
opening information. These both observation in combination with the third item from the 
list allow the following solution under the assumption that C1 is replaced by an extractable 
scheme. 

For a full-fledged corruption model, the simulator setups the NIZK schemes P1, P2 and P3 
for simulation and the commitment scheme C1 for extraction. When the simulator needs to 
simulate a message of an honest user towards a corrupted PoS/operator, it commits to some 
random value (which never needs to be opened) and simulates a proof exactly the same way as 
currently done in the case for user security. If the simulator plays an honest PoS (or operator) 
in an interaction with a corrupted user, the simulator extracts the user's secrets from the 
commitments (instead from the proof as it is done now in case of operator security) and inputs 
the extracted values into Faye. 

We stress that this modified proof strategy does not need any modifications on the protocol 
level. But it rules out shrinking commitments, because these go along with an information- 
theoretic loss and thus cannot be extractable. Hence, full UC security could be traded against a 
little less efficiency. 

We now consider the commitment scheme C2 for the prove-participation tags. Here, the 
same trick of an indirect opening can be applied. To this end, only the realization of the task 
ProveParticipation needs to be modified. The user does not unveil Coka directly and thereby 
shows that it contains pk,,, but instead the user sends a NIZK proof to the violation enforcer 
and thereby demonstrates that Cok, could correctly be unveiled. Note that this already happens 


in the context of Deposit when the (anonymous) user proves to the PoS that ku contains 


c 
p 
the correct value. The modification of ProveParticipation is cheap, as the proof is small and 
ProveParticipation is not time critical. Then C2 can be put into extraction mode for the security 


proof. For corrupted users the used pk, is extracted from in the scope of Deposit, while 


“pk, 
for honest users the NIZK proof is simulated in the scope of ProvePartisiparion: 

Lastly, we need to deal with the commitment scheme C4 which is used in IssueWallet and 
Deposit to jointly draw a random serial number s by means of a Blum cointoss. At the moment, 
C4 is either setup for equivocation (in case of operator security) or for extraction (in case of 
user security) to consistently simulate the cointoss for either side. Surely, the same trick could 
be applied again: Instead of opening the commitment cz, to the share s", the operator could 
send a NIZK proof and show an indirect opening. However, opposed to ProveParticipation 


this is computationally prohibitive as Deposit is a time critical task. But a much easier solution 
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is possible. If the interface of fpc is changed as outlined in Section 10.1.1 such that the serial 
number s is removed from the input/output, then the necessity to simulate a consistent Blum 
cointoss is remedied. Instead, a random commitment could be used to simulate the cointoss 
blindly. 

In summary, full simulatability under arbitrary corruption is possible in exchange for a 
different (less efficient, non-shrinking, extractable) instantiation of C1and a minor modification 


of ProveParticipation. 


An Open Problem The unmodified poof as presented in Chapter 8 and especially in Sec- 
tion 8.4 uses the NIZK scheme to assert that corrupted users indeed know their committed 
secrets, i.e. the NIZK proofs are proofs of knowledge. The proposed modification moves this 
attestation from the NIZK proofs to the commitments and thus allows to prove full-fledged 
security using a different proof strategy. However, the modification does not affect the NIZK 
scheme at all. Especially an adversary does not gain any further capabilities how to create NIZK 
proofs and cannot (and must not) know whether the NIZK scheme is running in extraction 
mode or not. Hence, from the adversary's perspective it does not make any difference, if the 
true value is extracted from the NIZK proof (given the prerequisite that it the CRS is setup this 
way) or if the true value is extracted from the commitment scheme. 

Let's express the idea differently: In theory, a non-extractable (and shrinking) commitment 
scheme might quash security, because the adversary might be able to find a way to send 
commitments whose message is not known by the adversary itself at the time when the 
commitment is sent, e.g. the adversary could try to blindly forward a commitment from 
another message and get away with it. However, this kind of attack is ruled out by the zero- 
knowledge proof of knowledge. Hence, as long as the NIZK scheme has the knowledge property, 
switching the commitment scheme between a non-extractable (and shrinking) or an extractable 
commitment scheme does not open up room for attacks. However, the adversary does not 
know, if the CRS of the NIZK is setup for extraction. 

This leads to the conjecture that the inability to prove the unmodified protocol zpsc secure 
under arbitrary corruption is not a real insecurity of the scheme, but a formal problem of 
the proof strategy. Hence, it is tempting to assume that zpsc is also secure under arbitrary 
corruption using shrinking (non-extractable) commitments. Finding an adequate proof strategy 


seems interesting. 


10.3 Summary and Future Work 


In this thesis we have formalized the concept of anonymous point collection as an abstract build- 


ing block. The proposed definition does not only heavily extend the functional requirements of 
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such a building block over previous approaches and thereby widens the practical applicability, 
but also is—to the best of our knowledge—the first one that provides a comprehensive definition 
as an ideal functionality in the UC framework and thereby treats correctness, security and 
privacy in an integrated way. A realization has been constructed (in pseudo-code) and formally 
been proven secure. Again, to the best of our knowledge, the rigorous and thorough security 
analysis of our building block is the first one in its area, i.e. among comparable proposed 
building block which target similar scenarios. Along that way a lot of technical subtleties had 
to be considered to eventually find a definition of security that is not overly idealized and thus 
cannot be realized on the one hand, but still captures a meaningful notion of security and is 
not too weak on the other hand, while allowing for a practically efficient realization at the 


same time. The resulting building block is the first one that 
(1) allows for anonymous two-way transactions, 
(2) has (periodic) offline capabilities, 
(3) requires only constant storage size (with respect to the balance), and 
(4) is provably secure. 


Moreover, the proposed construction has been actually implemented on real-world hardware to 
document its efficiency for practical deployment. Here, a challenging task has been to select the 
right set of instantiations of the building blocks which could be fine-tuned to nicely interplay 
with each other. The last two points have to be entirely credited to the author's co-workers. 
However, this thesis' contribution should not only be perceived as an improved definition 
and construction of an abstract building block for a specific purpose, but this thesis also 
demonstrates that the UC framework is the "right" method to formalize the security and 
privacy of complex systems. This thesis’ genesis is a perfect evidence: In [Nag+17] operator 
security as well as user security and privacy are treated as different problems. Operator security 
is formalized under the game-based paradigm using a list of desired properties and an individual 
game per property. User security is already formalized under the simulation-based paradigm, 
but rather in an ad-hoc model than a rigorously defined model such as the UC framework. 
Especially, this ad-hoc model is not very precise on how the simulator knows which user needs 
to be simulated, the simulator simply “does the right thing". In [Nag+20] the system is modeled 
in the UC framework, but ignores the synchronization of the distributed state. Instead Nagel 
et al. [Nag+20] vaguely states that the tags “somehow” roam from one party to the other. Both 
transitions from [Nag+17] to [Nag+20] and from [Nag+20] to this thesis have unveiled flaws 
in the previous attempt which have turned out to be oversights and would have allowed for 


real-world attacks. 
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This thesis also has shown how the classical game-based approach that uses a list of individual 
objectives can be combined with the simulation-based paradigm. Surely, a list of individual 
security properties (as in the game-based approach) tends to be more appealing as each of the 
security games is usually connected to a desired objective while an ideal functionality (for 
a complex system) tends to deprive itself from an immediate interpretation. But, the game- 
based approach has the inherent problem that it remains unclear when the list of properties is 
complete. In other words, each of the security games rules out a certain attack (e.g. claiming 
a wrong balance), but there is no guarantee what else may go wrong beyond that list. En 
contraire, the simulation-based approach is very good at making explicit what cannot be 
achieved. Starting with an overly ideal functionality more and more “backdoors” for the 
simulator are incorporated until it becomes realizable. For each backdoor there must either 
be a justification why it is inherent to the problem and thus cannot be avoided or a better 
realization must be contrived. This thesis gives an example how both methodologies can be 
combined for a complex system: At first a list of desired objectives is compiled, but then an 
ideal functionality needs to be defined. Instead of showing that a particular realization fulfills 
each objective by means of an individual security game, one shows that the ideal functionality 
fulfills the objective as done in this thesis in Sections 5.1 and 5.2. 

The same approach also lends itself for a privacy analysis of a complex system as shown in 
Section 5.3. Instead of analyzing the privacy for a concrete (cryptographic) realization and a 
concrete dataset (for a particular deployment), the privacy should be analyzed using the ideal 
model. The ideal functionality abstracts away the cryptographic complexity and “pulls it out 
of the equation". 

Although this thesis has (hopefully) contributed to the question how the security of complex 
systems can be captured, it has unveiled two problems which we deem interesting for further 
(long-term) research. Anonymous point collection might be a complex system from the usual 
cryptographic perspective compared to much simpler primitives like encryption, signatures, 
commitments and so on, but is by far not a complex system from the perspective of IT security 
(or even general software engineering) which deal with much larger systems. Nonetheless, 
already for this middle-size systems UC proofs become cumbersome and tedious, which might 
also explain why rigorous formal treatment at the same level of granularity is less common in 
the IT security domain. In the author's personal opinion, two problems need to be overcome 
to remedy this issue: (1) The UC framework needs to be relaxed (or extended) such that 


modular proofs are not only a theoretical promise, but actually possible in a way that reflects 


* Indeed, one of the (anonymous) reviewer of [Nag+20] declared to feel more confident about the security of the 


scheme, if there were individual security games instead of a single ideal functionality, because the functionality 
were a complex protocol on its own and it was hard to tell what security it provides. 
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the way how existing building blocks are combined in practice (cp. Section 5.4.3). (2) We 
require tools that allow computer-aided, automatic proofs of indistinguishability between ideal 
functionalities and their realization. Automated reasoning about security properties has gained 
much attention in the IT security field. However, existing tools (e.g. ProVerif, CryptoVerif, etc.) 
are usually very good at showing that given a certain set of pre-conditions the execution of 


some code fulfills some post-conditions and thus are very close to the game-based approach 
[Bla+18]. 
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Notation 


Identifier Definition Description 
do € Ap Operator attributes 
ap € Ap PoS attributes 
Ap = GY Set of operator/PoS attributes 
dy € Ay User attributes 
Ay = G) Set of user attributes 
b € Z, Balance of the wallet 
B € Z Base or ^width" for the chunks of the wallet ID; 
fixed system parameter 
bla > 9 Blacklist of fraud-detection IDs; used by PoSes 
Cay € © Commitment on fixed part of the wallet 
Cok, € G Hidden user ID; part of Opp 
Cs eo Commitment on the PoS' share of the serial number 
Cupd € G Commitment on the updatable part of the wallet 
Cid € G Commitment on the user’s share of the wallet ID 
certo = (pruPpd, 99,05") Operator self-signed certificate 
Certo = (pkp. ap, og) PoS certificate 
dg, € G Opening for cg, 
dy. € G Opening for Cok,» Part of Yop 
di € Z5 Opening for cér 
dung € G Opening for Cupd 
dig € G Opening for c; ig 
fap D PIDp > Ap (Partial) mapping assigning 
a PoS attribute ap to a PoS PID pid, 
fau : L> Ay (Partial) mapping assigning 
a user attribute aq, to a wallet ID A 
fs D P[Dy x I1 (Partial) mapping assigning a validity bit 
{OK, NOK} to a pair of user PID pid,, and proof of guilt r 
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Identifier Definition Description 

j € N Dimension of the user attribute vector; 
fixed system parameter 

t € N Number of chunks the wallet ID is split into; 
fixed system parameter 

n N Security parameter 

p € Zp Price to pay at an PoS 

p e P Prime-order of the underlying groups; 
fixed system parameter 

PlD corr C {0,1}* Set of identifiers of corrupted parties 

Pid pr € {0,1}* Party identifier of the dispute resolver 

pido € {0,1}* Party identifier of the operator 

pid, € {0,1}* Party identifier of a PoS 

PIDp > pidp Set of party identifiers of the PoSes 

pida, € {0,1}* Party identifier of a user 

PIDY > pid,, Set of party identifiers of the users 

Pkpr € GixGix(G2)U?x Public key of the dispute resolver 

(G2)* x (G2)? 
pko = (pk, pS“, pk™®’, Public key of the operator 
PR EDES) 

pk € Gfx G) +3 Public key of the operator for verifying 
a PoS-certificate; part of pko 

pk € Gix Gl Public key of the operator for verifying 
the fixed part of the wallet; part of pko 

peo € GixG Public key of the operator for verifying 
the updatable part of the wallet; part of pky 

pk € G?xG Public key of the operator for verifying 
the recalculation tag; part of pko 

pko ™ € G? xG? Public key of the operator for encrypting the 
recalculation tag; part of pko 

pkp € (pk? pkiS, pkBP) Public key of the PoS 

pk G? xG, Public key of the PoS for verifying 
the updatable part of the wallet; part of pkp 

pk e Gi Public key of the PoS for verifying 
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Notation 


Identifier Definition Description 

pkp € GxG Public key of the PoS for verifying 
the recalculation tag; part of pkp 

pku € G Public key of the user 

s € S Serial number 

S = 6 Space of serial numbers 

skpr € Ze Secret key of the dispute resolver 

sko = (sk, sko TE skype Secret key of the operator 

shee ke) 

sko " ez TP Secret key of the operator for certifying 
a PoS; part of sky 

sk € a Secret key of the operator for signing 
the fixed part of the wallet; part of sky 

skype e Zi Secret key of the operator for signing 
the updatable part of the wallet; part of sky 

is e Zi Secret key of the operator for signing 
the recalculation tag; part of sky 

ko e Zs Secret key of the operator for decrypting 
the recalculation tag; part of sky 

skp u (skpd, skp, skEP) Secret key of the PoS 

skupd Zi Secret key of the PoS for signing 
the updatable part of the wallet; part of skp 

sky € Zi Secret key of the PoS for signing 
the prove-participation tag; part of skp 

skp e Zi Secret key of the PoS for signing 
the recalculation tag; part of skp 

Skay € Za Secret key of the user 

t € Zy Double-spending response 

Un € Zp Double-spending mask 

Ug € Z, Double-spending challenge 

x € {0,...5%pounat (PRF) counter 

Xbound € N Upper bound on the number of transactions per 


wallet and upper bound on the number of fraud- 
detection IDs in blg per wallet; fixed system 


parameter 
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Identifier Definition Description 
y € No Dimension of the operator/PoS attribute vector; 
fixed system parameter 
A € Z, Wallet ID; used as PRF seed 
L > A Set of wallet IDs 
A € Z, User's share of the wallet ID 
LH € {0,...,B—1} A chunk of the user's share of the wallet ID 
A” € Zy Operator’s share of the wallet ID 
T Depending on context an arbitrary ZK-proof 
or a proof of guilt 
II > g Set of T's 
p € G; Fraud-detection ID 
o > 9 Set of fraud-detection IDs 
oe € G2xG Signature on (pk? i dg) under ko part of certo 
ont € G2xG Signature on (pkp, ap) under pko s part of cert 
Opx € G? x Gy Signature on (cg,, 4q) under pio. 
the fixed part of the wallet 
Opp € G2xG Signature on Cp, under pki; 
part of Ypp 
Ore € G2xG Signature on (s, p, g?) under pk" s) pkp; 
part of the recalculation tag We 
Cupd € G2xG Signature on (Cupa: 5) under pk? or pkp; 
the updatable part of the wallet 
Yl € (Gx G3) x Gite x Gr Encryption of (Af,..., At 4, A", pkq,) under pk pp; 
part of the blacklisting tag 
Yop = (KP, Opp, d oky) Secret part of prove-participation tag 
Yre = (5,9, p, pkp» Oc) Secret part of recalculation tag 
Oy = QUAND Blacklisting tag 
Qu > 0 Set of blacklisting tags 
ds = (g,t, ug) Double-spending tag 
Qa. > ás Set of double-spending tags 
Opp = pk, Prove-participation tag 
App > Opp Set of prove-participation tags 
Ore {0, 1}* Recalculation tag; encryption of yy under pk" 
Qc > Ore Set of recalculation tags 
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In numerous user-centric, cyber-physical systems, point collection and 
redemption mechanisms are a core component. Loosely speaking, this 
component may be viewed as personal “piggy bank” that allows users 
to deposit and disburse points. Depending on the context, points might 
be interpreted in numerous ways: monetary units, loyalty rating points, 
reliability credits, etc. 

Applications which are currently deployed in practice do not provide ano- 
nymity for the users. In the literature, several privacy-preserving solutions 
have been proposed. However, these proposals typically target specific 
scenarios, but do not consider anonymous point collection as a generic, 
multi-purpose building block. 

This work is a comprehensive, formal treatment of anonymous point col- 
lection. The proposed definition does not only provide a strong notion 
of security and privacy, but also covers features which are important for 
practical use. An efficient realization is presented and proven to fulfill the 
proposed definition. The resulting building block is the first one that al- 
lows for anonymous two-way transactions, has semi-offline capabilities, 
yields constant storage size, and is provably secure. 
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